Hi, Mark,
After I edited Run.ash as you suggested, I got the error message:
##################################################
Segmentation fault (core dumped)
##################################################
And there is a new file 'core' created in the directory, which I couldn't
view its content with vim or emacs.
As I don't think I need to run divcon on this machine, and you said it may
not be worth spending a lot of time on it, but I don't quite understand what
do you mean by 'run with the status quo'? can you please explain a bit more
for me? and as this is only still for serial parts, can I proceed to compile
the parallel parts? As I have tried, but with dozens of error messages.
Best regards,
Rachel
On 11/23/06, Mark Williamson <Mark.Williamson.imperial.ac.uk> wrote:
>
> >
> > I have spent some time searching in the maillist, haven't got any clues
> > to fix it. Thank you in advance for any suggestions.
> >
> > Best regards,
> >
> > Rachel
> >
>
> Hi,
>
> It seems that divcon is crashing as it is being used by antechamber.
> Running divcon outside of the Run.ash script may give more information
> about the nature of the crash:
>
> 1) cd $AMBERHOME/test/antechamber/ash
>
> 2) The Run.ash script cleans up after itself, but you need the divcon.in
> file that is generated earlier on in the script. Therefore
>
> a) Edit Run.ash to comment out the following lines like so:
>
> #/bin/rm -f ANTE* ATOMTYPE.INF BCCTYPE.INF FOR* NEWPDB.PDB PREP.INF \
> # leap.log prmcrd divcon.dmx divcon.rst divcon.in
>
> b) Run the ./Run.ash so that the above files are created, but not deleted.
>
> 3) Now run divcon explicitly using divcon.in as its runtime instructions:
>
> $AMBERHOME/exe/divcon divcon.in
>
>
>
>
>
>
> If this does not provide any more details to solve the problem, you may
> get more information if you run divcon inside a debugger (a debugger is
> a tool for dissecting a program and is used to track problems). To do
> this, you will first need to tell the compiler to add debugging symbols
> to the divcon binary when it builds it. One needs to recompile (in the
> way that you have done before) with a config.h that has the extra option
> set:
>
> cd $AMBERHOME/src/
> edit config.h
> set the parameter:
> AMBERBUILDFLAGS=" -g"
> save it
> make clean
> make
>
>
> Now run the debugger on the binary:
>
> cd $AMBERHOME/test/antechamber/ash
> gdb $AMBERHOME/exe/divcon
> <some text about gdb>
> (gdb) run divcon.in
> ***program crashes***
> (gdb) bt
>
> The output from this will give clues on why the program crashes.
>
> I suspect that the machine you're using does not have gdb, hence you
> will need to use whatever debugger is present on it. I think the IBM
> debugger is called "dbx" and the analogous "bt" command is "where". I
> think the "run" command is the same. I have very very little experience
> with such IBM machines, hence I'm quite out of my depth. Maybe someone
> else on the list could add in here.
>
>
> The use of a debugger is generally considered advanced for a standard
> user and hence may be painful :) You could alternatively run with the
> status quo; as long as sander passes all of its tests, and you're not
> going to use divcon on that machine you can probably proceed. This is
> not optimal, but neither is wasting enormous amounts of time on a
> problem that may not need to be solved.
>
> regards,
>
> Mark
>
> http://dumb.ch.ic.ac.uk/~mjw99/
> -----------------------------------------------------------------------
> The AMBER Mail Reflector
> To post, send mail to amber.scripps.edu
> To unsubscribe, send "unsubscribe amber" to majordomo.scripps.edu
>
-----------------------------------------------------------------------
The AMBER Mail Reflector
To post, send mail to amber.scripps.edu
To unsubscribe, send "unsubscribe amber" to majordomo.scripps.edu
Received on Sun Nov 26 2006 - 06:07:13 PST
