To re-install CHARMM, eg with new arguments to install.com:
rm (or mv) exec/<machine>/charmm
rm build/<machine>/pref.dat (if you made changes to pref.dat that you want to keep, don't do this step!)
Changes to the main makefile should be made to build/<machine>/Makefile_<machine> (not to build/<machine>/Makefile), in which case you should not remove it.
After a source-code change it should be sufficient to just do install.com ... (with the same flags as for the original installation).
Thanks very much!
It's very useful.
I've done some more recent playing around and have found that
doesn't work so well (at least not as I once thought it did). It isn't replaced if deleted. I've found that for cases of maintaining separate CHARMM executables with and w/o the X11 graphics, or with and w/o an added ab initio QM package, it is necessary to do
rm -rf build/<machine>
in order to force the re-creation of Makefile_<machine> with the proper options. This means that any customization of e.g. Makefile_gnu needs to be done in the build/UNX subdir; one should take care to preserve the original (make a copy).
Thanks very much for the information. You are absolutely right, the thing is that I have to remove (manually) all the folders and reconfigure and re-make it. I did not do it , I was using the non-parallel version with mpirun, that causes the error.
I am just curious why they donot specify the prefix for the installation path (like many of the other open source software), and separate the configuration and the final installation files….or, am I missing that?
And, is there any c version of charmm? the install.com seems have tons of issues regarding the machine types... Because, even I finally put the charmm into the old machine as parallel version, I have at least three other types of machines to install later version charmm, frankly speaking, I am terrified for these tasks cause there will be so many "tips" and "hints" and "tricks" which I have no idea ... Just hope it will not drive me into complete nut.
But again, thanks so much for the information. I just hope later on there will be less such “tips”, “hints” or “tricks”. It is REALLY very bad for whoever want to use this software, not mentioning to pay for it, maybe I shall not comment on it, cause it is free already –sort of—for researchers. But, if I were Karplus, I will just hire a bunch of c programmer to re-write the whole thing instead of keep adding patches into it and release endless documentations.
Most of the issues have little to do with C vs. Fortran, but with an overly complicated build procedure that's difficult to maintain and poorly documented.
A language change is underway, but to Fortran90.
I am running CPT MD simulation in hpz800 workstation it's have 8 processor. My simulation system having 27993 atom and time step 0.001. For simulating 500ps it's taking 22hr. Why speed of simulation is so slow.
i did charmm installation using
./install.com em64t xlarge M MPICH +CGENFF
please suggest me
Method and option choices can have major impacts on performance. Also, the new c36bN versions are a bit faster as well.
Learn to use the "New Topic" button for new topics.
For a system of this size you should be getting seveal ns/day on 8 cores.
Your installation is OK. Are you sure you are running 8 cores in parallel?
Performance depends on:
List generator. BYCB should be used for large systems.
Hello, Can AOCC compiler compile Charmm?
A compiler suite that includes both Fortran90 and C is required.
The build procedures are currently tailored to GCC and Intel suites, as those are widely used an known to produce working, stable executable programs. Using some other compiler may require some development effort, both in the code and the build procedures.
Your duplicate post has been deleted.