jonekoo / coarsemc Goto Github PK

Should the analysis codes be added to this repository? Some of them depend heavily on the ptgbcyl package, some less so.

• Instructions to the manual
• Input creation
• Output verification
• Analysis?

Now the requirement is python 2.6 or higher but actually the scripts don't work and were not meant to work with Python 3. Python 2 is already outdated and with probably small changes one could make all scripts compatible with Python 3.

If the inputfile does not contain a box, the program segfaults. Should spit an error to guide the user. Similar to #2.

In the case of an error occurring, there should be a systematic way to find out which part of the code raised the error, what was the possible cause, etc.

At the moment there are no plans from my part to develop the code further but maybe somebody could find pieces of it useful. Anyway in the name of open science it would be nice to have the code available for anyone to see. Are there any issues why it should not be releaesed or things that should be fixed/removed before release @borbware ?

The replacement rules are
PTGBCYL -> CoarseMC
ptgbcyl -> coarsemc

Many routines that don't actually use the RNG have to pass it around and thus become dependent on at least the interface of the RNG. One could e.g. create a factory of RNG:s and each routine that really needs the RNG could then call the factory for a RNG or just ask for a random number. Maybe it is not even necessary to have separate generator instances for different threads. For MPI processes the separate instances are probably needed.

When populating the cell list fails, for example Invalid cell index 0 1 0 and the particle coordinates and box is printed. This does not directly tell the user what could be done to prevent the error.

Could actually remove doxygen doc generation altogether and start using FORD.

Often it is OK to use a default value and this should not yield a scary warning during initialization. An info message would be better.

This would hugely decrease disk space requirements for trajectories. Could also increase performance significantly when writing trajectories. The problem can of course be the portability of the files.

At the moment the pFUnit is available in the repository but if at any stage the repository is about to be made public, the pFUnit must be removed since we do not have the right to distribute it along with our package. It would be nice though, if the user or (open source) developer could run the unit tests just by cloning the repository.

This would just be a cosmetic change to the code since the use of a separate group_names variable is a bit ugly. Not of high priority, though. Should not fix things which are not broken, but...

If particle_groups is missing, the program segfaults. Should spit out an error to guide the user and stop.
gdb output:

particlegroup could be an internal class of nvt_engine, since nvt_engine knows about the internals of particlegroup anyway. nvt_engine could be named as nonbonded_system or decomposed system. One would not have to give the interactions to it, since the now the system would own them. Parts of the mc_engine would become parts of decomposed system. Not of high priority anyway.

• Shorten the run time of the example
• Add instructions on running to the manual
• Creation of input?
• Verification of output?
• Analysis?

...since it is an ugly name.

I compiled the code from scratch (I was checked out to my separate "doublerod" branch with all the commits to master branch fetched on 23/6/2016).
I ran the configure script in a separate folder with the command
../ptgbcyl/gbcyl/configure FC=mpif90 FC=mpif90 FCFLAGS="-fno-range-check -O2 -fopenmp" CC=mpicc CFLAGS="-O2 -fopenmp" F77=mpif90 FFLAGS="-O2 -fopenmp"

After a successful make command, I ran make dist, and the compiler printed the following output:
https://dl.dropboxusercontent.com/u/22336072/sharetemp/makedist1.png

That is, it ran all the tests located at the "Tests" folder. Obviously, this shouldn't be happening.