This is a report on a bug that a programmer working for me, David
Coss, encountered while in the process of setting up sander to run
under control of BOINC for grid computing. Essentially, BOINCs policy
of unique file names, plus a name mangling protocol can result in
unusually long filenames, and at times this caused sander to stop with
an error. I've attached a message from him describing his isolation of
and fix for the problem.
Don Bashford
Department of Structural Biology
Saint Jude Children's Research Hospital
Memphis
Email Disclaimer: www.stjude.org/emaildisclaimer
attached mail follows:
Here's a description of the declaration conflict, where it can be found and how I fixed it. Hope it helps. If not, let me know.
--David
In sander, variables that store file names are declared to have a length of 256 characters in files.h. However, in the subroutines load_ewald_info and peek_ewald_inpcrd, both found in ew_setup.f, variables parm and/or inpcrd are declared to have a length of 80 characters within the scope of those subroutines. In both subroutines, the variables are used as filenames for amopen; in load_ewald_info, this occurs via the subroutine AMOEBA_check_newstyle_inpcrd found in amoeba_interface.f . The subroutines AMOEBA_check_newstyle_inpcrd and amopen use a variable length for the file name, which is why this problem does not occur elsewhere, at least in my use of sander. Changing the length to 256, in agreement with the declaration in files.h, solved this problem; although, one could argue that if an absolute path is used, 256 characters could be too little.
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Mon Nov 01 2010 - 09:30:04 PDT
