Project Name

[jhprinz]

Just to collect ideas separately for a while...

About the name. So this package effective allows to sample ensembles of paths. So something with these three words?

• PathFinder
• PES (PathEnsembleSampling) Groups of paths might form a "Flow"?
• FlowSampling

Lots of paths form a street (Autobahn) a map

• PathMapper
• EnsembleMapper
• MapSampler

Cartography?

[jchodera]

Some other random names:

• pathr
• path-ensemblr
• OpenPathSampling
• pathmc
• Path Prospector

[jhprinz]

Prospector sounds cool

What other things helps to find a way/path

• Compass
• Guide

[bolhuis]

Hi,

I think that the final name choice is rather important.

The name of the package should reflect: -the fact that it is based on the path sampling methodology -the relation to OpenMM and other python based packages -the flexibility of the code to the user

I kind of like the following: OpenPathSampling (OPS) OpenPathEnsembleSampling (OPES) PathSampler (PS)

could OpenTIS and MSM-TIS be sub packages or so under the umbrella of OpenPathSampling or is that too complex?

Names with Map or Mapper are going to cause difficulties with other schemes like DiffusionMap etc.

Best, Peter

On 09 Nov 2014, at 16:30, John Chodera notifications@github.com wrote:

Some other random names:

pathr path-ensemblr OpenPathSampling pathmc Path Prospector — Reply to this email directly or view it on GitHub.

prof. dr. Peter Bolhuis

Amsterdam Center for Multiscale Modeling Computational Chemistry and Physics van 't Hoff Institute for Molecular Sciences (HIMS) University of Amsterdam PO Box 94157 1090 GD Amsterdam, The Netherlands

phone: +31-205256447 email: p.g.bolhuis@uva.nl

[jchodera]

Good points, @bolhuis!

It may be easiest to pick a good name for the overall package, like OpenPathSampling, and have subpackages adopt a more Pythonic convention, so that the user would be writing:

from openpathsampling import tis
from openpathsampling import msmtis
...

I'd be happy with something like this!

[dwhswenson]

In at least those specific cases, I'm not sure that subpackages make sense. For example, msmtis would just be MSM-based interfaces on TIS. So part of the setup might look like the following:

from openpathsampling import EnsembleFactory as ef
import openpathsampling as paths

op = paths.orderparameter.MSMOrderParameter(setup_options)
interface0 = ef.TISEnsemble(op, 0.0, 1.0)
calc = paths.PathSampling(setup_options)

The point is the code re-use: TISEnsemble is useful for any TIS simulation (as well as for AMS, for example). The PathSampling calculation type is used for both TPS and TIS (and possibly others; depends on how we define "moves" in replica space). The only thing specific to MSM-TIS is the single class MSMOrderParameter; after all, that's what distinguishes it from older TIS implementations!

In fact, I think that's one of the conceptual points we're making with this code: a lot of these methods are very closely related, and so they should share a common code base. (We're certainly not the first to make that point, but it is a nice one.) So I'm not sure that trying to make separate subpackages for these is best. Even AMS is only separated from TIS by having a different GlobalStateMover and (possibly) a different Calculation subclass.

(Also, as used above, regardless of final choice for the full name, I kind of like using the namespace paths; the other choice might be ps, but I think paths does well enough, and won't conflict with Postscript.)

[jhprinz]

I also like using openpathsampling with paths for the project in short.

[dwhswenson]

Sounds like we have settled on OpenPathSampling, and @jchodera got us the URL and opened an issue to change the repo name (and with that that, we should change the directory, although we should probably hold off on that until current branches are merged in.)

Anyway, all of that is just to say that I'm closing this issue; remaining aspects are in other issues already open!