 |
SEARCH
TOOLBOX
LANGUAGES
Forum Menu
util file name resolve: filename too small
From NWChem
Viewed 2633 times, With a total of 7 Posts
|
|
|
|
| 2:18:38 AM PDT - Tue, Sep 20th 2011 |
|
Recently, I used mp2 level to calculate qmmm, but nwchem could not run. And who can help me to solve this problem?
The error informations are as follows:
NWChem Property Module
----------------------
------------------------------------------------------------------------
util_file_name_resolve: filename too small 257
------------------------------------------------------------------------
------------------------------------------------------------------------
current input line :
44: task qmmm mp2 optimize
------------------------------------------------------------------------
------------------------------------------------------------------------
There is an error in the input file
------------------------------------------------------------------------
For more information see the NWChem manual at
http://www.emsl.pnl.gov/docs/nwchem/nwchem.html
util_file_name_resolve: filename too small 257
------------------------------------------------------------------------
------------------------------------------------------------------------
util_file_name_resolve: filename too small 257
My nw flie is as follow:
start 2HJ4_mp2_opt
memory total 3000 Mb
prepare
read 2HJ4_mp2_opt.rst
write 2HJ4_mp2_opt_0_bak.rst
end
task prepare
basis
* library 6-31g*
end
mp2
print high
print "basis"
print "geometry"
print "information"
print "pair energies"
print "partial pair energies"
print "progress reports"
print "reference"
end
md
system 2HJ4_mp2_opt
sd 2000 init 0.01 min 1.0e-5 max 0.05
cutoff 1.0 qmmm 1.0
noshake solute
print step 1 extra
print energies 1
end
qmmm
region qm mm_solute solvent
method bfgs lbfgs sd
maxiter 200 2000 2000
ncycles 20
density espfit
end
task qmmm mp2 optimize
prepare
read 2HJ4_mp2_opt.rst
write 2HJ4_mp2_opt_0_final.pdb
end
task prepare
|
|
|
-
Bert Forum:Admin, Forum:Mod, NWChemDeveloper, bureaucrat, sysop
|
|
|
Forum Vet
Threads 4
Posts 597
|
|
| 3:15:01 PM PDT - Tue, Sep 20th 2011 |
|
It looks like you have a very long file name, which is the full path name plus the file name, that exceeds 255 characters, it actually needs 257 characters. Or you reduce your path length a little, or (if you compiled the binary yourself) you can change the default path length to a larger value in src/util/util.fh. nw_max_path_len = 255, increase the value here. You will have to do a "make realclean" and recompile the code.
Thanks,
Bert
Quote: Sep 20th 9:18 amRecently, I used mp2 level to calculate qmmm, but nwchem could not run. And who can help me to solve this problem?
The error informations are as follows:
NWChem Property Module
----------------------
------------------------------------------------------------------------
util_file_name_resolve: filename too small 257
------------------------------------------------------------------------
------------------------------------------------------------------------
current input line :
44: task qmmm mp2 optimize
------------------------------------------------------------------------
------------------------------------------------------------------------
There is an error in the input file
------------------------------------------------------------------------
For more information see the NWChem manual at
http://www.emsl.pnl.gov/docs/nwchem/nwchem.html
util_file_name_resolve: filename too small 257
------------------------------------------------------------------------
------------------------------------------------------------------------
util_file_name_resolve: filename too small 257
My nw flie is as follow:
start 2HJ4_mp2_opt
memory total 3000 Mb
prepare
read 2HJ4_mp2_opt.rst
write 2HJ4_mp2_opt_0_bak.rst
end
task prepare
basis
* library 6-31g*
end
mp2
print high
print "basis"
print "geometry"
print "information"
print "pair energies"
print "partial pair energies"
print "progress reports"
print "reference"
end
md
system 2HJ4_mp2_opt
sd 2000 init 0.01 min 1.0e-5 max 0.05
cutoff 1.0 qmmm 1.0
noshake solute
print step 1 extra
print energies 1
end
qmmm
region qm mm_solute solvent
method bfgs lbfgs sd
maxiter 200 2000 2000
ncycles 20
density espfit
end
task qmmm mp2 optimize
prepare
read 2HJ4_mp2_opt.rst
write 2HJ4_mp2_opt_0_final.pdb
end
task prepare |
|
|
|
|
|
|
| 6:32:49 PM PDT - Wed, Sep 21st 2011 |
|
| I have tested the above two methods, but it still could not work. So I don't know why. And who can help me?
|
|
|
|
|
|
|
| 6:35:50 PM PDT - Wed, Sep 21st 2011 |
|
| The full path name plus the file name actually did not exceed 255 characters. I don't know why. Who can tell me the reasons?
|
|
|
-
Bert Forum:Admin, Forum:Mod, NWChemDeveloper, bureaucrat, sysop
|
|
|
Forum Vet
Threads 4
Posts 597
|
|
| 10:52:27 AM PDT - Thu, Sep 22nd 2011 |
|
I assume your error message was different?:
util_file_name_resolve: filename too small <larger value you set it to>
Can you do a grep on "permanent" and "scratch" in the output file and post that information.
Also, can you post the current error message plus the nw_max_path_len you set (copy of the src/util/util.fh would work).
You did a "make realclean" at the src level right, not just the src/util directory? At the src level, after the "make realclean", do a "make nwchem_config ..." and make.
Bert
Quote: Sep 22nd 1:35 amThe full path name plus the file name actually did not exceed 255 characters. I don't know why. Who can tell me the reasons? |
|
|
|
|
|
Clicked A Few Times
Threads 4
Posts 12
|
|
| 9:06:42 PM PST - Tue, Nov 8th 2011 |
|
Hi everybody...
As it turns out, I'm having the same problem, trying to run the NEB example that I downloaded from http://www.nwchem-sw.org/images/QMMM_NEB_example1.tgz. I get the same error when attempting to run my own NEB input script (modeled on the example). I found a description of the same problem on the old EMSL mailing list (http://www.emsl.pnl.gov/docs/nwchem/nwchem-support/2010/11/0001.Re:_NWCHEM_Error_running_N...), but couldn't track down the solution. I tried following the suggestion that Marat posted there and adding
set qmmm:neb_region qmlink
to my input file, but this didn't have any noticeable effect. The error message is:
util_file_name_resolve: filename too small 262
For the record, the full path of the directory I'm running this in is only 33 characters long. When I tried relocating to a directory that is only 30 characters long, the error message is still
util_file_name_resolve: filename too small 262
so I suspect this isn't the problem. When I rename my scratch directory from ./data to ./d there is no change; renaming the permanent directory from ./perm to ./p changes the error output to
util_file_name_resolve: filename too small 259
finally, when I change the line specifying the permanent directory in the input file from
permanent_dir ./p
to
permanent_dir /home/craig/Projects/nwchem/q/p
the error message is now
util_file_name_resolve: filename too small 287
reflecting the difference in length between those directory names. It looks like NWChem is trying to append a string that is already 256 characters long to whatever permanent directory name I give it.
Finally, if I try extending the length of the filename buffer by modifying src/util/util.fh to
parameter (nw_max_path_len = 511)
and rebuild (after a "make realclean") the error message is unchanged. I poked around a bit in util_file_name.F, but I don't know fortran so I've reached the limit of my debugging abilities. How should I modify util_file_name.F to tell me what the offending file name actually is? Any other ideas about what to try next?
Thanks,
-craig
|
|
|
|
|
|
|
| 9:39:27 PM PST - Sun, Nov 13th 2011 |
|
Hi again...
I added some debugging code to util_file_name_resolve so that it now looks like this:
subroutine util_file_name_resolve(filename, oscratch)
implicit none
#include "errquit.fh"
#include "inp.fh"
#include "util.fh"
#include "global.fh"
character*(*) filename ! [input/output]
logical oscratch ! [input]
c
c If the given filename is not a full path (begins with /)
c or explicitly relative to the current directory (./ or ../)
c then resolve it to the scratch/permanent directory for the
c current process according to oscratch.
c
c Note that this resolution cannot happen at input time since only
c process 0 reads the input and the directories are process specific.
cc
character*(nw_max_path_len) dir
integer flen, dlen
c
if ((filename(1:1).ne.'/') .and. (filename(1:2).ne.'./')
$ .and. (filename(1:3).ne.'../')) then
call util_directory_name(dir, oscratch, ga_nodeid())
dlen = inp_strlen(dir)
if (dlen .gt. 0) then
flen = inp_strlen(filename)
write(*,*) "filename: ", filename(1:flen)
write(*,*) "dir: ", filename(1:dlen)
write(*,*) "flen: ", flen
write(*,*) "dlen: ", dlen
write(*,*) "len(filename): ", len(filename)
write(*,*) "nw_max_path_len: ", nw_max_path_len
if ((flen+dlen+1).gt.len(filename)) call errquit
$ ('util_file_name_resolve: filename too small',
$ flen+dlen+1, INPUT_ERR)
dir(dlen+1:dlen+1) = '/'
dir(dlen+2:) = filename
c
* write(6,*) ' RESOLVED ', filename(1:flen), ' TO ',
* $ dir(1:inp_strlen(dir))
c
filename = dir
endif
endif
c
end
The six lines that all start with "write(*,*)" are my debugging output. The output I get from NWChem immediately before the crash now looks like:
neb: Calculating Initial Path Energy
filename: <gibberish>
dir: <gibberish>
flen: 255
dlen: 6
len(filename): 255
nw_max_path_len: 511
So the value of nw_max_path_len appears not to affect the size of filename at all, and it looks like this function is being called with filename uninitialized. Note that the output didn't actually say "<gibberish>" it gave a bunch of unformatted garbage that I couldn't successfully paste into a Wiki post.
The offending call to util_file_name_resolve() is in run_bead_list, on line 355 of src/optim/neb/bead_list.F, where it's being passed a character string (of hard-coded length 255) called perm_name that is returned by rtdb_cget:
value = value.and.
> rtdb_cget(bead_rtdb,rtdb_name,1,perm_name)
call util_file_name_resolve(perm_name, .false.)
As far as I can tell, rtdb_cget pulls character variables from the run-time database. I really don't know the structure of the code well enough to know at what point the relevant variable is being put into the run-time database, or whether it's being pulled out correctly. I should point out that if I change the last line of the input script from
task qmmm dft neb
to
task qmmm dft energy
then the single-point energy calculation works fine and my debugging code reports a single (apparently successful) call to util_file_name_resolve. If anyone is familiar with this part of the program, I would really appreciate any ideas you have, because I'm really stuck at this point, and all I'm trying to do is run the example provided in the NWChem documentation!
Thanks,
-craig
|
|
|
|
|
|
Clicked A Few Times
Threads 4
Posts 12
|
|
| 6:56:58 PM PST - Sun, Nov 27th 2011 |
|
So I think I've resolved the problem -- the call to rtdb_cget that I quote above (from bead_list.F) involves an uninitialized variable 'value' (or so gfortran told me during compilation). It looks like what happens here is that rtdb_cget is never actually called at all (to avoid doing anything dangerous with an expression containing an uninitialized variable), so perm_name is never initialized and util_file_name_resolve never gets a comprehensible filename to resolve. Other fortran compilers might be able to avoid this problem (since the uninitialized value doesn't seem to actually get used for anything important) but it leads to a bug when you compile with gfortran.
To get around this, just insert the line 'value = .true.' before the call to rtdb_cget that is quoted above; then everything works fine.
--craig
|
|
|
AWC's:
2.5.10 MediaWiki - Stand Alone Forum Extension
Forum theme style by: AWC
| |
