Opened 7 years ago
Closed 7 years ago
#1342 closed defect (fixed)
Atoms.aniso_u(6) hides data
Reported by: | Tristan Croll | Owned by: | Tom Goddard |
---|---|---|---|
Priority: | moderate | Milestone: | |
Component: | Core | Version: | |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Notify when closed: | Platform: | all | |
Project: | ChimeraX |
Description
Would be really good to have these carry through to the output PDB when they're present.
Related: at present, Atoms.aniso_u
and Atoms.aniso_u6
both return None if any atom(s) in the list don't have ANISOU records. The default behaviour in other packages seems to be to instead provide an array with the entries corresponding to non-anisotropic atoms filled with NaN. I guess there are arguments either way, but it seems counter-intuitive to return None where (some) data actually exists.
Change History (4)
comment:1 by , 7 years ago
Priority: | major → moderate |
---|---|
Status: | assigned → accepted |
follow-up: 2 comment:2 by , 7 years ago
Clarification: `Atoms.aniso_u` returns None if any atom in the array has no aniso_u. `[a.aniso_u for a in atoms]` where atoms is an `Atoms` object will give the expected result, but is inevitably slow. The approach I currently use is to pre-populate a numpy array with NaN, then fill it: anisos = numpy.ones((len(atoms),6))*numpy.nan mask = atoms.has_aniso_u anisos[mask] = atoms[mask].aniso_u6 ... which works fine in scripts, but isn’t great when tinkering in the interactive shell. A fairly small thing on the whole. The PDB output issue is my main concern. Tristan Croll Research Fellow Cambridge Institute for Medical Research University of Cambridge CB2 0XY
comment:3 by , 7 years ago
Component: | Input/Output → Core |
---|---|
Owner: | changed from | to
Status: | accepted → assigned |
Summary: | ANISOU records not written to PDB files → Atoms.aniso_u(6) hides data |
Have fixed the problem of PDB not outputting ANISOU records. Reassigning to T.G. for second part since he implemented those functions.
comment:4 by , 7 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
I've made Atoms.aniso_u and Atoms.aniso_u6 raise a ValueError exception if any atom in the collection does not have aniso values.
I think this is better than using NaN values. Any code that handles some but not all atoms having aniso_u has to check has_aniso_u. Raising an error makes sure the problem is caught immediately. Using NaN allows calculations to produce wrong numbers creating debugging headaches.
To be clear about the second part, you're saying that if any atom lacks ANISOU info then *all* atoms return None as their info -- rather than just the lacking atoms returning None and the others returning numerical info? The former would certainly be wrong.