On Sat, Jan 22, 2011 at 10:10 AM, case <case.biomaps.rutgers.edu> wrote:
> On Wed, Jan 19, 2011, Ross Walker wrote:
> >
> > With regards to the X Motif libraries the best approach is probably to
> have
> > the configure script test if they are there and skip things if they are
> not.
> > The alternative is too include the X Motif libraries in AMBER Tools and
> > build them as part of the build process. I don't like this approach
> though.
> > Lots of people have been doing it of late with NetCDF, Boost, Python etc
> and
> > it is just leading to total bloat.
>
> There are a variety of points here that need to be considered:
>
> 1. Download size is becomming an issue. Here are some current sizes:
>
> boost for mtkpp: 16 Mb
> boost for gleap: 29 Mb
> python: 70 Mb
> netcdf 18 Mb
>
But these are uncompressed file sizes (and netcdf in a clean tree for me is
only 10 MB to boot). Even adding the 34 MB pnetcdf package, the total size
contributions of these 5 packages together is 18 MB zipped. This accounts
for only about 10% of the total size of the package. As a comparison, this
is the size of the unzipped bugfix.11 that amber11 users are required to
download (since we don't offer a zipped alternative).
> The current AmberTools tarball (*after* bzip) is 152 Mbytes, and we
> have users on slow connections. The key size problems are in the test
> cases, some of which are *huge*; but trimming code could also be a plus.
>
If the download speed is a serious issue, can we not offer to burn CDs with
the source code and ship those out (with compensation for our costs, of
course)? We could even bundle it with the printed manuals in some way if
there are no legal or other roadblocks stopping that. Trimming the tests
per Dan's suggestion, while thankless, will probably accomplish more than
ripping out 3rd party packages (I, like Dan, am biased toward the packages I
find particularly helpful/beneficial, as I appreciate having an Amber
python). At the very least, I agree with Dan (and probably everyone else
that has an opinion), that netcdf (if not pnetcdf) should be kept
regardless.
>
> 2. I am really more worried about code portability than bloat per se.
> For the most part the complicated stuff (mpi, netcdf, boost, python)
> actually compiles OK, and we would probably cause more grief by telling
> people
> to go download these from other sources than by having a version that we
> know
> works included. [In the past, the boost code in particular greatly limited
> the number of compilers that could be used; I don't know if that is so true
> anymore.]
>
> However, we often want to compile (parts of Amber) on specialized machines
> that
> don't conform to the Linux/Unix/Mac expectations for an environment. I
> think
> it is pretty easy for an experienced person to do that, but we should
> continue
> to make this as simple as we can.
>
> 3. We should have a discussion of Ross' point at the developers' meeting.
>
We will certainly not lack for things to discuss.
All the best,
Jason
> ...dac
>
>
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
>
--
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Graduate Student
352-392-4032
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sat Jan 22 2011 - 11:30:04 PST
