Fix lammps #472
Fix lammps #472
Conversation
|
... well, #359 should not be in a 0.12.1 because it is a new feature. |
- moved all LAMMPS files into lammps/ subdirectory - removed lammps2.data and lammps2.dcd (were not used and unknown provenance) - added freshly generated DCD with dt=0.5 ps for testing - added the LAMMPS input file for the new test data - install new files (setup.py)
- LAMMPS default time unit is fs (for unit real, see http://lammps.sandia.gov/doc/units.html) but we had it as ps - Universe(..., dt=<dt>) is working now for DCDReader (and anything derived from it such as the LAMMPS DCDReader)
| @@ -115,7 +115,7 @@ | |||
| 'data/*.trz', | |||
| 'data/mol2/*.mol2', | |||
| 'data/capping/*.gro', 'data/capping/*.pdb', | |||
| 'data/*.data', | |||
| 'data/lammps/*.data', 'data/lammps/*.data.bz2', 'data/lammps/*.dcd', 'lammps/*.trz', | |||
There was a problem hiding this comment.
the .in file needs to be here too?
There was a problem hiding this comment.
No, in file is not needed to run the tests, just in case we want to rerun LAMMPS again to generate a DCD, eg with different settings.
Oliver Beckstein
email: [email protected]
skype: orbeckst
Am Oct 6, 2015 um 9:49 schrieb Richard Gowers [email protected]:
In testsuite/setup.py:
@@ -115,7 +115,7 @@
'data/.trz',
'data/mol2/.mol2',
'data/capping/.gro', 'data/capping/.pdb',
'data/*.data','data/lammps/_.data', 'data/lammps/_.data.bz2', 'data/lammps/_.dcd', 'lammps/_.trz',—
Reply to this email directly or view it on GitHub.
|
@richardjgowers , don't merge yet. From the coverall report of LAMMPS.py I see that the LAMMPS |
Introduced an experimental class-attribute flavor for the DCDReader/DCDWriter that helps to distinguish the CHARMM DCD code from the LAMMPS code (and later will be useful for the NAMD DCD Reader/Writer in #359 ) Added tests to check that the LAMMPS DCDWriter and Reader are being used because the last coverage report said that the LAMMPS.DCDWriter was not being covered.
|
I think it;s good to go now; coverage on LAMMPS.py 100% https://coveralls.io/builds/3765917 |
|
.. although I am still puzzled why LAMMPS.DCDWriter was not picked up previously in the coverage report. |
|
I am done on this one. |
|
Something is not quite working on travis during the automatic doc building: https://travis-ci.org/MDAnalysis/mdanalysis/builds/83997576#L3105 , the 'python setup.py build _ext --in-place` seems unhappy (and I think that worked before). Any ideas? EDIT: proper link to build log |
|
.. perhaps related to moving the compiled files elsewhere #444 ?? |
|
I think you could use |
|
https://travis-ci.org/MDAnalysis/mdanalysis/builds/83504869#L3033 It looks more like the scipy bug you found before, that I'm also getting here? |
|
If it's the conda/scipy bug then change .travis.yml according to MDAnalysis/GridDataFormats#17 |
|
I'll have a look at the doc builds later, need to do some other non-MDA stuff, too.... |
To just build stuff in-place use 'python setup.py build_ext --inplace'. This will only build the c-extensions in the current project directory. The develop flag is additionally installing an symbolic-egg-link so that you can use a module in the development stage in your global environment. |
@richardjgowers : these fixes should make it into 0.12.1 (and possibly #359 if I get to it)