Re: Unable to read corrupted binary DCD trajectory file

From: Kenno Vanommeslaeghe (
Date: Mon Sep 08 2014 - 13:08:11 CDT

On 09/08/2014 01:26 PM, Ajasja Ljubetič wrote:
> - Windows is not an operating system for serious computational
> science. For starters, a lot of important softwares in the field are
> not natively supported, and one needs to install compatibility layers
> like Cygwin to access them as well as to tap the powers of the UNIX
> shell, which are almost indispensable in this line of work.
> I partially disagree. (I have been using namd on windows for ~5 years with
> major problems).

I assume you meant "without major problems"? Regardless, your previous
statement "I usually just write each ns length of simulation to it's [sic]
own DCD, thus avoiding such problems" illustrates my point, being that the
intersection between the minority that uses Windows and the minority that
writes monolithic trajectory files is small enough for an (as for now
hypothetical!) flaw like this to go undetected for a long time...

> A unix shell is easily installable using git for windows
> <> (and Console2
> <> gives you a super terminal).
> This takes about 5 min to set up.

Sure, you can add MinGW+MSYS to that list, which is quite excellent and
integrates well with native Windows stuff. In the end, it's still software
you need to install and maintain up-to-date separately from the O/S, while
you get the same (and much more) out-of-the-box in Linux. A long time ago,
I used to work in a Windows environment, made bearable through a list of
extra softwares and heavy customization. Life (especially the professional
part of it) became much easier after switching to Linux.

> The real problem is compiling stuff on windows... :)

Exactly. The "advanced usability issues" such as lack of a decent shell
out-of-the-box was not exactly the most important of my objections...
compatibility with academic software is.

This archive was generated by hypermail 2.1.6 : Thu Dec 31 2015 - 23:21:13 CST