util file name resolve: filename too small

From NWChem

Viewed 1887 times, With a total of 7 Posts
Jump to: navigation, search

  • Guest -
    Send PM
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
    Profile
    Send PM
Forum Vet
Threads 5
Posts 598
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 am
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

  • Guest -
    Send PM
I have tested the above two methods, but it still could not work. So I don't know why. And who can help me?

  • Guest -
    Send PM
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
    Profile
    Send PM
Forum Vet
Threads 5
Posts 598
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 am
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?

Clicked A Few Times
Threads 4
Posts 12
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

  • Guest -
    Send PM
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
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


Forum >> NWChem's corner >> QMMM



Who's here now Members 0 Guests 1 Bots/Crawler 0


AWC's: 2.5.10 MediaWiki - Stand Alone Forum Extension
Forum theme style by: AWC