Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DCDReader units are not handled consistently #475

Closed
orbeckst opened this issue Oct 6, 2015 · 4 comments
Closed

DCDReader units are not handled consistently #475

orbeckst opened this issue Oct 6, 2015 · 4 comments

Comments

@orbeckst
Copy link
Member

orbeckst commented Oct 6, 2015

tl;dr: Manipulating the "native units" of the different DCDReader flavors (CHARMM, LAMMPS, soon NAMD) is probably still buggy and needs a few eyes.

The way we can force different units for the DCDReader(s) is still murky. PR #472 addresses some problems (in particular, it actually enables setting dt as kwarg). If one wants to change the unit of time or length one uses lengthunit or timeunit kwargs (to Universe, which passes through to the DCDReader). The native units of the reader are stored in DCDReader.units.

For the LAMMPS flavor of DCDReader it is common to change the units as a user (see units style command) so there's code to change LAMMPS.DCDReader.units. For the CHARMM flavor we don't do that (and units is class level, so it would be a bad idea to change it).

  • Should we put all DCDReaders on the same footing and make native units changeable with kwargs? Or should we say that "CHARMM DCD" is defined to be AKMA/Å units and if you need something else you need to use a less stringent reader (e.g. LAMMPS or NAMD)?
  • Do units properly propagate through the 'OtherWriter()' method that is supposed to give a writer that produces a copy of the trajectory? Should it use original native units (and dt) or propagate the user-set length- and time-unit and dt?

I want to introduce a NAMD flavor #359 as well, and, because the underlying DCDReader C-code is actually a NAMD reader, this would become the "base" implementation of DCDReader, with other flavors being derived from it.

@orbeckst
Copy link
Member Author

I think the CHARMM DCDReader/DCDWriter should use fixed units because this is how CHARMM handles trajectories:

  • time: AKMA
  • length: Å

(An issue remains how we actually store unit cells in the DCD file (see #187); for as long as we are using the catdcd DCD code, we will be storing it in NAMD format – #359).

@richardjgowers
Copy link
Member

So I don't fully understand all the permutations of DCD.. but what seems to make sense to me is something like...

class DCDReader:
    default_units = {}  # default units for DCDReader
    def __init__(self, **kwargs):
        # the units for this instance of Reader are from kwargs, or use the class defaults
        self.units = self.units.update(kwargs)

class CHARMMDCDReader:
    default_units = {AKMA & A}

I think this achieves both the scenarios in your first point, at the cost of having a few extra Classes.

With fetching Writers, it makes sense for a new Writer to have the default units of the class, unless kwargs say otherwise. But maybe as a convenience, some sort of same_units kwarg to get a Writer with the same units.

@orbeckst orbeckst removed the question label Dec 28, 2015
@orbeckst orbeckst added this to the 0.13 milestone Dec 28, 2015
@orbeckst
Copy link
Member Author

@richardjgowers's suggestion sounds good. Maybe I make a DCD subdirectory with the different flavors.

(I added it to 0.13 because it should be addressed together with #359 but if might get retargeted...)

@orbeckst orbeckst self-assigned this Dec 28, 2015
@orbeckst orbeckst modified the milestones: 0.13, 0.14 - Topology refactor Jan 7, 2016
@kain88-de kain88-de mentioned this issue Oct 2, 2016
12 tasks
@orbeckst orbeckst mentioned this issue Jul 2, 2017
4 tasks
@orbeckst
Copy link
Member Author

In some way the DCD cython re-implementation #1372 made this issue superfluous: we established that CHARMM and NAMD DCDs have the same units. They do differ by unitcell representation but that's a different issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants