[gmx-developers] Documentation of internal environment variables

[Mark Abraham]

On 9/03/2012 11:16 AM, Christoph Junghans wrote:
> Dear all,
>
> I was thinking of adding an overview table to the manual documenting
> some internal used environment variables.
> Should we do that?

I've long thought this is a good idea. I suggest we open a Redmine issue 
so that we can't make a new release without choosing to ignore 
documenting this in the manual (!)

Manual appendix A.4 has a few definitions, but some probably are out of 
date. Various tools' help text have other clues. Hopefully code comments 
will help too.

>
> find . -name "*.[ch]" -exec sed -n 's/.*getenv(\([^)]\+\)).*/\1/p' {}
> + | sort -u
> gives the following list:
> "ACC" "BASENAME" "CPMCSCF" "DEVEL_DIR" "DISPLAY" "DISTGCT" "DSSP" env
> env_var "GALACTIC_DYNAMICS" "GAUSS_DIR" "GAUSS_EXE" "GKRWIDTH"
> "GMX_ALLOW_CPT_MISMATCH" "GMX_CAPACITY" GMX_CHECK_MPI_ENV
> "GMX_CONSTRAINTVIR" "GMX_CYCLE_ALL" "GMX_CYCLE_BARRIER"
> "GMX_DD_ORDER_ZYX" "GMX_DISRE_ENSEMBLE_SIZE" "GMX_DUMP_NL"
> "GMX_ENX_NO_FATAL" "GMXFONT" "GMX_FORCEINIT" "GMX_FORCE_TABLES"
> "GMX_FORCE_UPDATE" "GMXGHAT" GMX_IGNORE_FSYNC_FAILURE_ENV "GMXLIB"
> "GMX_MAXBACKUP" "GMX_MAXCONSTRWARN" "GMX_MAXRESRENUM"
> "GMX_MAX_THREADS" "GMX_NB_GENERIC" "GMX_NBLISTCG" "GMX_NO_ALLVSALL"
> "GMX_NO_CART_REORDER" "GMX_NOCHARGEGROUPS" "GMX_NO_FFRTP_TER_RENAME"
> "GMX_NO_INT" "GMX_NO_NODECOMM" "GMX_NOOPTIMIZEDKERNELS"
> "GMX_NOPREDICT" "GMX_NO_PULLVIR" "GMX_NO_QUOTES"
> "GMX_NOSEHOOVER_CHAINS" "GMX_NO_SOLV_OPT" "GMX_NO_TERM" "GMX_NO_USR1"
> "GMXNPRI" "GMXNPRIALL" "GMX_NSCELL_NCG" "GMX_PATH_GZIP"
> "GMX_PME_NTHREADS" "GMX_PMEONEDD" "GMX_PME_THREAD_DIVISION"
> "GMX_SCSIGMA_MIN" "GMX_SUPPRESS_DUMP" "GMXTIMEUNIT" "GMX_TPIC_MASSES"
> "GMX_TPI_DUMP" "GMX_VIEW_XVG" "GMX_VIRIAL_TEMPERATURE" "LOG_BUFS"
> "LOGO" "LONGFORMAT" "MDRUN"  "MEM" "MPIRUN" "MULTIPROT" "NCPUS"
> "ORCA_PATH" "PATH" "SASTEP" "STATE" "TESTMC" "TOTAL" "VERBOSE"
> "VMDDIR" "VMD_PLUGIN_PATH" "WHERE" "XMGR"
>
> Which are the important ones?

If they're important enough to be available to the user, they're 
important enough to document. If there's not enough clues in the code, 
then "git blame" will identify the guilty party who needs to contribute 
some documentation to their code, and then to the manual section :-)

Mark