One of the most important things, when running a program, is to understand its error and warning messages. MAIN is programmed so that it shouldn't crash whatever a user oess. (Crashing can unfortunately not be completely disabled.) There are two kinds of errors; syntax errors, which are relatively easy to find, and data errors arising from the missing or incompatible data. The later sometimes result in a zero divide or similar.
Each error message starts with descriptive name of subroutine as for example "READ_COOR>". Most of error messages include the string %ERR or %ERROR, so that they could be easier localized in the output file by using a SEARCH or 'grep' utility. When looking for mistakes don't disregard %WARNINGS. "The most important is the first error message." All the other usually result from the first one.
When MAIN can not interpret a command sentence, one or a series of error messages appears on the default output.
For example the command sentence
MAIN>read laksjdf
results in the following
CMD_READ> %ERROR: COMMAND NOT ON THE LIST - POSSIBLE WORDS:
analysis atoms coordina bonds hbonds
ctable elements internal points topology
paramete sequence symmetry cell map
stream reflecti scatteri ztable help
CMD_READ> %ERROR: NO OBJECT FOR READING SPECIFIED
UNPROCES> %ERROR: NOT PROCESSED STRING(S): 1
read laksjdf
^^^^^^^^
The first error message lists the list of possible command words. The second error messages (if it shows up) tells something about the nature of the mistake and the last part is the message about unprocessed words (their number is given), the whole command sentence is repreated and unprocessed words are underlined. The first underlined word is almost always the cause of the problem.
Arguments are strings, integer numbers, atom ids (numbers) and real numbers.
MAIN command parser can do some type conversions (integer to reals and strings, reals to strings), but not others. These type of errors are detected by the command parser and result in a message like this one:
MAIN>set vari xx real = a
CMD_SET_VARI> %ERROR: I EXPECT A REAL HERE
UNPROCES> %ERROR: NOT PROCESSED STRING(S): 1
set vari xx real = a
^
If the argument is inappropriate (has a wrong or invalid value) you will get a kind of message as below, where the file does not exist.
MAIN>read file oo coor pdb
FILE_OPEN> %ERROR {oo}
But, sometimes the messages are not that as evident as in the case above. In the case below the map 3 does not exist and number 4 is more than one higher than existing number of maps. So the parser interprets the argument "4" but does not know what to do about it.
MAIN>make map 3 from 4 init cell grid 10 10 10
CMD_MAKE_MAP> %ERROR: INTEGER NOT FOUND
UNPROCES> %ERROR: NOT PROCESSED STRING(S): 12
make map 4 from 3 init cell box 10 10 10 grid 10 10 10
^^^^ ^ ^^^^ ^^^^ ^^^ ^^ ^^ ^^ ^^^^ ^^ ^^ ^^
This completely valid statement wants to access the atom number which does not exist:
MAIN>set center atom 10 GET_CENT> %ERR ATOM NUMBER NOT FOUND
There are more kinds of the SELECTION errors:
Quite often a KEY you want to apply does not exist or is empty.
> show key
may give you some idea.
MAIN is quite well protected against syntax errors. The data errors are harder to find and analyse. The messages are diverse or may even not exist. The program may do nothing, but also not crash.
The most common error is that you hit some array boundaries. Specifying your own array sizes will probably work.
> show sizes > set sizes ?
Sometimes it may help to increase the LEVEL of messages by a SET LEVEL command. It works for sure when there is a corrupted record in the input file, because reading of a file was interrupted exactly there.
SHOW, WRITE and IMAGE command may be very helpfull.
> show box
may point out that some of your atoms are out in space.
There is always one more bug is a very ture statement. Also MAIN is not free of them. When you find one, please report it. Much more common than the MAIN executable program bug is a bug within the MAIN macros, which are simpler to fix.
When you have a problem, restart the session by copying its contents from the "input.cop" file into a restart file and run it to reproduce the crash. If it is not reproducable, it is not MAIN dependent. If it is reproducable, try to figure out how far you can simplify the case by reducing the number of commands in the restart file and send me the session.
It helps to exchange data and repeat the whole thing with a smaller molecule or map. When an error is data related you will not observe it again. This should make you think about your data. MAIN may help you to debug this problem too.
If the bug is in a macro, even if you don't know exactly which line, send me an e-mail and I will probably easily correct it. If it is in the MAIN executable file send me an e-mail about it and ask for a new executable. Remember that long input and output files hinder me from finding the errors in script or in source.
If you can not go on send an e-mail.
When no error message occurs and nothing happens
It usually means that you and MAIN do not agree what parameters, selections, variables and maybe also data forms are necessary to achieve your goals. Use of SHOW and WRITE commands may help you to resolve the problem. It is not unwise to contact a more experienced user about this, because these problems are usually trivial, but you may waste unbelivable amounts of time or just quit using the program.
A very often the "WORK_SEGM" variable does not contain your segment names. The commands
> show vari WORK_SEGM > show segm
will tell you with which segment names the menu macros are dealing with and which segment names are known to the program.
Fload of error and warning messages
Try to find out what the first one means.
Usually this happens when you try to read in a coordinate file which does not correspond to residue descriptions provided by topology libraries. It is unwise to ignore them, because usually in the fload of incompatibility problems there are also some related to bad geometry (too close contacts resulting in wrong connections, etc).
Clicking "xpl2MAIN" on page 7 should reduce the fload and another "DEFINE" will point out the rest of problems.