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

write a test for spherical selections tokens using the periodic kdtree #1733

Merged
merged 7 commits into from Jan 21, 2018

Conversation

jmborr
Copy link
Contributor

@jmborr jmborr commented Dec 11, 2017

Fixes #1731

IN PROGRESS

PR Checklist

  • Tests?
  • Docs?
  • CHANGELOG updated?
  • Issue raised/referenced?

@richardjgowers
Copy link
Member

This looks like it'll be a good addition. If we can get the kdtree version of all selections working, we should probably make that the only option.

@jmborr
Copy link
Contributor Author

jmborr commented Dec 12, 2017

@richardjgowers I just opened issue #1736 to test cylindrical selections 😄

@jmborr
Copy link
Contributor Author

jmborr commented Dec 12, 2017

@orbeckst @richardjgowers I'm running into a bit of a problem here. test_atomselections.py uses trajectory file adk_dims.dcd which when loaded results in dimensions=[0, 0, 0, 90, 90, 90]. Two distance-based selection tests taking into account periodic boundary conditions are failing because of this.
Do you know how can one end up with such bizarre dimensions?

@orbeckst
Copy link
Member

orbeckst commented Dec 12, 2017

The trajectory was simulated without PBC. If you need a trajectory with PBC, use TPR/XTC.

You could fudge the PSF/DCD test by setting the dimensions to some reasonable value before doing the selections. (u.atoms.bbox() might help to get a tight box)

Incidentally, failing with undefined box is a good corner case to catch.

@jmborr
Copy link
Contributor Author

jmborr commented Dec 12, 2017

@orbeckst So do I understand that if I load a trajectory with no PBC, MDAnalysis will always assign dimensions=[0, 0, 0, 90, 90, 90] instead of dimensions=None or is this just some bizarre occurrence?

@orbeckst
Copy link
Member

Yes, that's what we put when there is no box.

@jmborr
Copy link
Contributor Author

jmborr commented Dec 12, 2017

OK, then I'll insert a box checking to prevent the combination of dimensions=[0, 0, 0, 90, 90, 90] and the default MDAnalysis.core.flags['use_periodic_selections']=True to end up fooling DistanceSelection.apply()

@richardjgowers
Copy link
Member

richardjgowers commented Dec 12, 2017 via email

@orbeckst
Copy link
Member

The topology says nothing about the box. The trajectory has box information – or not. However...

I checked for our XYZ example, which does not contain box information, and I get dimensions == array([ 0., 0., 0., 0., 0., 0.], dtype=float32).

Thus, it is not true that we always set the box to [0, 0, 0, 90, 90, 90] when we don't have the box. Sorry @jmborr , I was wrong. It seems that we are not handling this case uniformly and have left it to the reader implementation. For example, the DCD reader code initializes lengths to 0 and angles to 90º

unitcell[0] = unitcell[2] = unitcell[5] = 0.0;

whereas the XYZ reader just uses the base defaults (all 0).

Barring a comprehensive survey, I am assuming that having no box information will at least lead to

all(dimensions[:3] == 0) == True

(or the float equivalent np.allclose())

@orbeckst
Copy link
Member

(I opened #1738 so that this point is not forgotten.)

@richardjgowers
Copy link
Member

I think the hack here for dimensions is fine, and then one day in the future we'll have nicer handling that is universal across the package

@jmborr
Copy link
Contributor Author

jmborr commented Dec 15, 2017

@orbeckst @richardjgowers I'm having an error with one of the builds that seems unrelated to the code changes. Have you ever encountered something similar?

@orbeckst
Copy link
Member

I've seen this one before. For some reason, on the Mac OSX workers, pytest sometimes fails to create a temp directory; possibly an issue with the xdist plugin for running in parallel (??). Not quite sure. (Or maybe we wrote an incorrect pytest fixture somewhere.)

I restarted https://travis-ci.org/MDAnalysis/mdanalysis/jobs/315961274 , maybe it goes away...

@orbeckst
Copy link
Member

I restarted the Mac OS X travis job again, but if it fails again, I'd be willing to ignore it.

Copy link
Member

@orbeckst orbeckst left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor changes as far as I can see.

Maybe @richardjgowers or @kain88-de can also have a quick look?

Returns
-------
None or numpy.ndarray
Returns argument dimensions if system is periodic, otherwise
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This description "if system is periodic" is ambiguous because self.periodic is an external choice if periodicity ought to be taken into account. Can you please say more clearly what goes into deciding if None or the box is returned?

Also make clear that we only consider full 3D periodicity as periodic, we don't support periodicity in only some dimensions (or arbitrary space group operators... that would be fun).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then the wording can be changed "periodic in all three dimensions" and the validation code can be changed to:

if self.periodic and all(dimensions[:3]):
    return dimensions
return None

What do you think?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, sounds good.

ref = sel.center_of_geometry().reshape(1, 3).astype(np.float32)

box = group.dimensions if self.periodic else None
periodic = False if self.validate_dimensions(group.dimensions) is None\
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shorter

periodic = self.validate_dimensions(group.dimensions) is not None

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But even better, rearrange your code to avoid calling the same method twice:

box = self.validate_dimensions(group.dimensions)
periodic = box is not None
ref = sel.center_of_geometry(pbc=periodic).reshape(1, 3).astype(np.float32)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

ref = sel.center_of_geometry().reshape(1, 3).astype(np.float32)

box = group.dimensions if self.periodic else None
periodic = False if self.validate_dimensions(group.dimensions) is None\
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shorter

periodic = self.validate_dimensions(group.dimensions) is not None

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But even better, rearrange your code to avoid calling the same method twice:

box = self.validate_dimensions(group.dimensions)
periodic = box is not None
ref = sel.center_of_geometry(pbc=periodic).reshape(1, 3).astype(np.float32)

@orbeckst
Copy link
Member

Please also update CHANGELOG and docs - probably somewhere under selections.

@jmborr jmborr force-pushed the 1731_spherical_tokens_pkdtree branch from e295452 to ff7f4d9 Compare January 12, 2018 22:44
@jmborr
Copy link
Contributor Author

jmborr commented Jan 13, 2018

@orbeckst One test is failing because of errors at the 12th decimal place. Is this accuracy unacceptable?

@orbeckst
Copy link
Member

orbeckst commented Jan 13, 2018 via email

@jmborr
Copy link
Contributor Author

jmborr commented Jan 15, 2018

@orbeckst There seem to be a conflict in the python 3.4 build because the numpy requirement is incompatible with this python version:

UnsatisfiableError: The following specifications were found to be in conflict:
  - numpy 1.14* -> python >=2.7,<2.8.0a0
  - python 3.4*
Use "conda info <package>" to see the dependencies for each package.

I guess this will affect all pull requests

@kain88-de
Copy link
Member

@jmborr I'll fix this on the build server sometime this week. Anything else effected by this PR?

@jmborr
Copy link
Contributor Author

jmborr commented Jan 15, 2018

@kain88-de If you want, you could take a look to this Mac OS-X build flagged as "allowed to fail".

@kain88-de
Copy link
Member

yeah, that is expected. No idea what is wrong with OSX right now. None of us has the time to look into it currently. Therefore it is set to be allowed to fail.

@jmborr
Copy link
Contributor Author

jmborr commented Jan 15, 2018

I travel in the same tight ship, so that's fine with me 😸

@kain88-de
Copy link
Member

You can restart the python 3.4 test if this PR is merged. conda-forge/numpy-feedstock#76

@jmborr
Copy link
Contributor Author

jmborr commented Jan 19, 2018

@kain88-de is the conda-forge/numpy-feedstock#76 PR on ice ?

@kain88-de
Copy link
Member

kain88-de commented Jan 19, 2018 via email

@jmborr
Copy link
Contributor Author

jmborr commented Jan 19, 2018

@kain88-de I wasn't aware Travis was having such an issue, good to know 👍

@orbeckst orbeckst merged commit b837af1 into MDAnalysis:develop Jan 21, 2018
@jmborr jmborr deleted the 1731_spherical_tokens_pkdtree branch January 22, 2018 18:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants