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

Different units in analysis.LinearDensity #2507

Open
lilyminium opened this issue Feb 6, 2020 · 3 comments
Open

Different units in analysis.LinearDensity #2507

lilyminium opened this issue Feb 6, 2020 · 3 comments

Comments

@lilyminium
Copy link
Member

lilyminium commented Feb 6, 2020

Expected behavior

MDAnalysis keeps consistent units of Angstrom for length, or documents when it doesn't.

Actual behavior

analysis.LinearDensity converts volumes from A^3 to cm^3

Code to reproduce the behavior

k = 6.022e-1 # divide by avodagro and convert from A3 to cm3

This isn't in the docs.

Currently version of MDAnalysis

  • Which version are you using? (run python -c "import MDAnalysis as mda; print(mda.__version__)")
  • Which version of Python (python -V)?
  • Which operating system?
@lilyminium
Copy link
Member Author

lilyminium commented Feb 6, 2020

This also makes the header written in the file inaccurate. (charges are indicated to have e/A^3 density)

        header = ("1 coord [Ang] 2-7 mass density (x,sx,y,sz,z,sz) [g/cm^3]"
                  "8-13 charge density (x,sx,y,sz,z,sz) [e/A^3]\n Average "
                  "density: {} g/cm3".format(density))

Edit: the charges are not actually in e, they're in e*(Avogadro's number). Possibly the line below is unintentional.

self.results[dim]['char'] /= self.results[dim]['slice volume'] * k

@orbeckst
Copy link
Member

orbeckst commented Feb 7, 2020

@mattihappy can you clarify what was intended?

@orbeckst
Copy link
Member

orbeckst commented Feb 7, 2020

I would be in favor of using standard units, Å, and e/Å3.

For density, g/cm3 is more sensible than u/Å3.

Note that the save functions were removed #1745 (specifically PR #2487) so this boils down to

  1. documenting what is actually done
  2. deciding to change the output data without deprecation — do we want to and if so, what should be changed?

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