Hi all,
Regarding point 1, an AmberTools version that does not include 3rd
party libraries could be made available. The configure script would
just need to be able to look for these libraries if they aren't in the
Amber directory and take appropriate action and/or give helpful error
messages if they aren't found on the system. Since netcdf is
(hopefully) becoming the default trajectory format people are using I
think that should be kept no matter what; however I may be a little
biased there :-).
Regarding the test case sizes, one thing that I have tried to do with
the cpptraj test cases is to use one trajectory/prmtop in as many
tests as possible. While every possible trajectory type should be
represented in an entire test suite, there is no need for each test to
have it's own separate input trajectory and topology file. I will look
at the ptraj (and cpptraj if it will be included in AmberTools) test
cases and see what I can trim.
-Dan
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
>
> 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.
>
> 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.
>
> ...dac
>
>
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sat Jan 22 2011 - 10:30:02 PST
