Subject: Summary on MOPAC memory requirement

From: Victor Anisimov <[email-masked]>
Date: Sat, 15 Jun 1996 19:39:30 +0400

Dear netters,

Some weeks ago I posted a message with a problem
I've encountered. My letter was:

=Does someone have experience compiling MOPAC-93 for big
=dimensions, 100x100, 200x200 heavy and light atoms, for
=example. How much virtual space they will reqire?
=
=I'm getting "can't allocate memory" message on FreeBSD
=with 400Mbyte of virtual space on hard disk for 100x100 
=one.
=
=What is this, low virtual space or Fortran compiler error,
=does someone know?
=
=Thanks for any idea.
=Victor.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I'm very thankful to everyone who responced

Pedro A M Vazquez  <[email-masked]>
Georg Ostertag     <[email-masked]>
David E. Bernholdt <[email-masked]>
A J Turner         <[email-masked]>
Rainer Koch        <[email-masked]>
Serge Pachkovsky   <[email-masked]>
Mao                <[email-masked]>

My summary consist of three parts, first one have deal with virtual
memory size required by MOPAC, compilled with fixed number of heavy
and light atoms, second and third parts are concerned with resolving
of the problem I had and will spetially interested only those who
use MOPAC on PC with FreeBSD UNIX or considering to use FreeBSD 
may be in future. Third part gives a FreeBSD user a very usefull
advice how increase your swap capabilities without reformatting
your hard disk partitions.

>>>>>>>>>>>>>>>>>>>>>>>>>>>  1-st part  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Here is a summary table of virtual memory requirements (in Mb) for MOPAC 
with different number of Heavy and Light atoms on some platforms:

            30x30 50x50 60x60 70x70 80x80 90x90 100x100 150x150 200x200
-----------------------------------------------------------------------
DEC Alpha    27    39     -    83     -    127     -       -       -
IBM RS/6000   -     -     -     -    76     -     130     243      -
SGI R8000     -     -     -     -    65     -      -      208      -
FreeBSD      16     -    37     -     -     -      -       -       -

All the values I get from respondents, whom I'm very appreciated. 
Unfortunately I don't know author's MOPAC configurations, so to 
complete the picture and eliminate possible inconsistences
I report virtual memory requirements of MOPAC-93 tested (except 200x200, 
sorry for lack of resources) and compilled on my i486/FreeBSD with 8Mb RAM

FreeBSD*     13    30     -    75    96    120    147     320     578

These space requirements were derived with:
Ford's ESP                   Yes
Merz's ESP                   Yes
Green Function corr. to IP   No
COSMO                        Yes
Polarizability               Yes
MECI                         No
CI                           No
Pulay's SCF DIIS converger   Yes

Comparing the results from the table I have to agree with my 
respondents, that the size of mopac virtual memory requirements 
shows minor dependence from Operational System and hardware.
Of course, those data can be used only as a rough guide if one
will use different configurations, especially with CI or without COSMO
or ESP, nevetheless they can be surtanly useful for evaluation goals.

As an interesting result of capabilities to run big configured MOPAC 
on FreeBSD you can see successful test of 150x150 job on PC with only
8Mb RAM and with sufficient swap, of course. So you see there is no
obligatory requirements to fit job in RAM to make a smooth execution. 
Testing molecule had 20 atoms but because MOPAC does static memory 
allocation I suppose it is sufficient test. One reason of such success
could be advanced memory allocation kernel support from FreeBSD 2.1.0 
that used instead of standart buggy malloc library. If it's right it 
will need new tests with big molecule to be true.

>>>>>>>>>>>>>>>>>>>>>>>>>>>  2-nd part  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Second part is concerned with solving a problem I had. Many thanks to
Gary Palmer <[email-masked]>, Joe Greco <[email-masked]>
and espetially to David Greenman <[email-masked]>, who is a 
Core-team/Principal Architect of The FreeBSD Project.
As a short resume I was simply out of resources.

Gary Palmer explained that there is a per-process limit in FreeBSD to 
prevent a single process creating denial-of-service type attacks.
Those limits can be easy unlocked and to do it he recommends

Depending on your shell, try:

csh/tcsh:

limit datasize unlimited
limit stacksize unlimited
limit memoryuse unlimited

sh/bash:

ulimit -d unlimited
ulimit -s unlimited
ulimit -v unlimited

David Greenman recommended me to look on
/sys/i386/include/vmparam.h
where default limits are located.

There is a reason don't rely on "limit" command at all and to edit
your vmparam.h and recompile a kernel. You can see that vmparam
has not only default limit values but their maximum possible values
too. I experienced that you can not get unlimited resources via "limit"
command, the maximum you can have is described if vmparam.h.
So I recommend you to edit your vmparam.h and set new values for
some parameters. Here you see defaults sufficient to run MOPAC 200x200
and not only on your FreeBSD 2.1.0.

 *	from: @(#)vmparam.h	5.9 (Berkeley) 5/12/91
/*
 * Virtual memory related constants, all in bytes
 */
#define	MAXTSIZ		(64UL*1024*1024)	/* max text size */
#ifndef DFLDSIZ
#define	DFLDSIZ		(512UL*1024*1024)	/* initial data size limit */
#endif
#ifndef MAXDSIZ
#define	MAXDSIZ		(512UL*1024*1024)	/* max data size */
#endif
#ifndef	DFLSSIZ
#define	DFLSSIZ		(64UL*1024*1024)	/* initial stack size limit */
#endif
#ifndef	MAXSSIZ
#define	MAXSSIZ		(256UL*1024*1024)	/* max stack size */
#endif
#ifndef SGROWSIZ
#define SGROWSIZ	(128UL*1024)		/* amount to grow stack */
#endif

>>>>>>>>>>>>>>>>>>>>>>>>>>>  3-rd part  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Pedro A M Vazquez <[email-masked]>

recommend to use very nice FreeBSD UNIX feature to add specially
prepared continous file as swap device, that can increase swap
without reformatting disk. It is really very powerful capability
for quick management of swap space.
It requires kernel support for /dev/vn* pseudo devices, to do it
simply add next line to kernel config on desired number of swap
files (2 swap files, for example) and recompile the kernel:

pseudo-device   vn      2

After rebooting with new kernel type the commands

cd /dev; MAKEDEV vn0 vn1
dd if=/dev/zero of=/home/swap bs=1k count=100k
vnconfig -c /dev/vn0c /home/swap
swapon /dev/vn0c

You are adding so additional 100Kb of swap space. Now swapinfo
will report something like this:
Device      1K-blocks     Used    Avail Capacity  Type
/dev/sd0s1b     51200     4504    46632     9%    Interleaved
/dev/vn0c      102400       48   102288     0%    Interleaved
Total          153472     4552   148920     3%

Thanks if you could read this short ;-) summary. I'd like to
expect it will be useful for someone. 

Victor.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   ***     Institute of Chemical Physics in Chernogolovka     ***
   *                Russian Academy of Sciences                 *
   *                   Dr. Victor M. Anisimov                   *
   *      senior chemist and head of Networking & IT Dept.      *
   ***                   [email-masked]                    ***
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^