I agree with Jason's points, and since I like to do things "in the service
of others" I was thinking of volunteering my services to make it so that
the mdgx topology parser could serve nab. I can write good documentation
and think of what future developers may need. But, it will have to be
after the devs meeting. I'm not sure what will happen with the existing
ptraj, if people decide that cpptraj will now replace it.
But, I definitely don't want to end up throwing more on the pile of
standards.
Dave
> Sorry - couldn't resist: http://xkcd.com/927/
>
>> -----Original Message-----
>> From: dcerutti.rci.rutgers.edu [mailto:dcerutti.rci.rutgers.edu]
>> Sent: Tuesday, November 29, 2011 11:31 AM
>> To: AMBER Developers Mailing List
>> Subject: [AMBER-Developers] Topology file readers
>>
>> In the interest of making a targeted, focused discussion about an issue
>> that is causing some confusion at the moment and portends to cause
>> more,
>> I'd like to bring up topology readers. As I see it, we should
>> ultimately
>> support two, or perhaps three canonized readers, one for C, C++, and
>> Fortran. I argue that the differences between C, C++, and Fortran are
>> sufficient to warrant different data structures for each case, and even
>> if
>> there were some master object file that reads the topology and then a
>> series of converters to put it into different formats, there would be
>> about as much code to maintain as if we had three separate readers.
>>
>> My recommendation is that we select, perhaps at the devs meeting, the
>> readers that will serve in each capacity. The readers should all do
>> precisely the same things, even though information will get filtered
>> differently:
>>
>> - Collect contiguous arrays of charges, Lennard-Jones A and B, bond
>> stiffnesses, atom names, etc.
>> - Be compatible for parallel execution (i.e. read the topology file as
>> ASCII text and then parse the text, so that the text can be transmitted
>> through memory to other processes without having all processes trying
>> to
>> read directly from the disk)
>> - Collect all information deemed relevant by the current standard
>> - Be able to read old-style prmtops as well as "prmtop7" format, with
>> automatic detection ???
>> - Efficient! Clean-coded! Expandable, and robust!
>>
>> Comments welcome. At present, we'll probably need to decide amongst
>> the
>> readers for nab, mdgx, and ptraj, and the readers for sander and pmemd,
>> perhaps cpptraj and any other C++ based code in the tree.
>>
>> Dave
>>
>>
>> _______________________________________________
>> 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
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Tue Nov 29 2011 - 15:00:03 PST
