G.4.5 Tailoring the NEMO kernel

It can be handy to know what a minimum subset of library routines will be in order to run major portions of NEMO. Some of the comments below have never been tried out, so beware! Also some comments apply how to tailor certain routines for less functionality, if your local hostmachine is not as sophisticated. It is our intention to have them defined in a file options.h, although this may complicate multi-cpu shared source code. In such cases they may need to be defined via the cc script -D command line option, just as we currently use the -I switch.

The source code of most of the barebone NEMO library routines can be found in $NEMO/src/kernel/ and below.

loadobj.c: This has been discussed before, a proper symbol must be defined, in order for loadobj.c to include the correct loadobj source code type. Note that the trigger may be used for you if no symbol has been supplied. usually cpp supplies a trigger, such as sun, sparc, unicos, mips etc.

bodytrans.c: This routine is normally compiled with the -DSAVE_OBJ compilation switch in which case bodytrans functions, which are not yet found, will be saved to the standard repository directory $NEMOOBJ/bodytrans. this option is now standard defined in options.h.

getparam.c: This file contains many #define's which allow you to add a number of extensions to the user interface which have been discussed in Appendix : data history mechanism, interactive keyword and menu prompting, parsing of expressions of getXparam() variables, interrupt to the review section, remote machine execution, etc. For more documentation see the source code. none of these run through options.h though.

image.c: This routine handles all image i/o (e.g. read_image, write_image, create_image), and can be compiled in -DCDEF or -DFORDEF mode, depending how your matrices in c should be stored in memory. The fits interface may not work properly when the wrong def is used???