-
Notifications
You must be signed in to change notification settings - Fork 18
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
Centers fucntion is not giving the right coordinates #77
Comments
No, I don't think so. The origin itself is already the center of cell with index Or do you have any indication that origin is not a center itself? |
Those links explain that I have not run APBS in a very long time, but if you produce a .dx file with the
If I wanted the first grid "point" to be at x = -10, I would supply a minimum of -10.5 and a maximum of 10.5, for a total of 21 points in each dimension. |
If you look in the original DX specs (via archive) https://web.archive.org/web/20080808140524/http://opendx.sdsc.edu/docs/html/pages/usrgu068.htm under
and then
I read it that the entries in a DX file In principle the correct interpretation for volumetric data should be that origin and origin + n*delta are the centers of volume elements. Now, APBS has defined it differently
which I would argue violates the original DX specifications. Nevertheless, I understand that probably nobody who uses GridDataFormats cares about the original DX specs and most people care about reading APBS DX files and therefore users of GridDataFormats would prefer that we interpret APBS-style DX formats correctly. Given that I am also a user I am ok with breaking the original DX specs interpretation but we have to make sure that there's a way to get the "true" DX specs behavior if needed. I will comment on your PR #78 . |
@giacomofiorin thanks, could you comment on PR #78 ... I didn't see your comment while I was writing mine. |
@sobolevnrm we have a question regarding how APBS interprets OpenDX, in particular the
parameter. The APBS docs state
Does this mean
Thank you for your insights. |
Hi -- Interpretation (2) should be correct. Is this what you're observing?
…On Thu, May 14, 2020 at 1:31 AM Oliver Beckstein ***@***.***> wrote:
@sobolevnrm <https://github.com/sobolevnrm> we have a question regarding *how
APBS interprets OpenDX*, in particular the
origin xmin ymin zmin
parameter. The APBS docs
<https://apbs-pdb2pqr.readthedocs.io/en/latest/formats/opendx.html#opendx>
state
xmin ymin zmin
The coordinates of the grid lower corner
Does this mean
1. the *center* of the "grid lower corner" cell/volume element is
located at (xmin, ymin, zmin) (and then the left edge is at xmin - hx/2
etc), or
2. the *lower left front edge* is located at (xmin, ymin, zmin) (and
then the center of the cell is at xmin+hx/2, ymin+hy/2, zmin+hz/2)?
Thank you for your insights.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#77 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAOX7WCHVOSYMJ56GZJFQGLRROT43ANCNFSM4MKR53VA>
.
|
At the moment there's no observation. @acruzpr stated that the APBS docs seem to imply interpretation (2) (and I agreed with their reading #77 (comment) although @giacomofiorin was more dubious #78 (comment) ). @giacomofiorin (see #77 (comment)) and I (#77 (comment)) think that that this not the common interpretation of the DX file, according to specs and what VMD thinks. Can you think of a good way to test APBS's interpretation or is there an obvious place in the source code to look at? |
Hi All --
These should be good references:
https://github.com/Electrostatics/apbs-pdb2pqr/blob/master/apbs/src/mg/vgrid.c#L586
https://github.com/Electrostatics/apbs-pdb2pqr/blob/master/apbs/src/mg/vgrid.c#L1206
Please let me know if you have any questions.
Thanks,
Nathan
…On Mon, May 18, 2020 at 9:57 AM Oliver Beckstein ***@***.***> wrote:
Does this mean
- the center of the "grid lower corner" cell/volume element is located
at (xmin, ymin, zmin) (and then the left edge is at xmin - hx/2 etc), or
- the lower left front edge is located at (xmin, ymin, zmin) (and then
the center of the cell is at xmin+hx/2, ymin+hy/2, zmin+hz/2)?
Hi -- Interpretation (2) should be correct. Is this what you're observing?
At the moment there's no observation. @acruzpr
<https://github.com/acruzpr> stated that the APBS docs seem to imply
interpretation (2) (and I agreed with their reading #77 (comment)
<#77 (comment)>
although @giacomofiorin <https://github.com/giacomofiorin> was more
dubious #78 (comment)
<#78 (comment)>
).
@giacomofiorin <https://github.com/giacomofiorin> (see #77 (comment)
<#77 (comment)>)
and I (#77 (comment)
<#77 (comment)>)
think that that this not the common interpretation of the DX file,
according to specs and what VMD thinks.
Can you think of a good way to test APBS's interpretation or is there an
obvious place in the source code to look at?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#77 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAOX7WFCZ5DCCLLK5DW6ZATRSFSGXANCNFSM4MKR53VA>
.
|
@orbeckst in reading the ABPS doc and the comments by @sobolevnrm please remember the recommended number of grid points in ABPS, Let's make an example in 1D for simplicity. If I specify a domain length
and APBS outputs the potential sampled at each one of these points, and the corresponding DX file has an
@sobolevnrm Please correct me if needed. Now, when the map represents a histogram, such as what
(Feel free to replace of course the < sign with a ≤ sign if you want: I hope we agree that numerically it would hardly make a difference). It is important to note that the physical domain covered by that map starts at x = -11.25, because any x values between -11.25 and -10.0 will be counted in the first bin. Both use cases make up for an identical OpenDX header, but the physical or mathematical quantities represented by the data file are different, and this fact is not encoded by the format. Confusion arises primarily because the odd point added in the APBS calculation makes the extrema become "round" numbers. As a last counter-example, a histogram that covers the exact range [-10.0:10.0] and has the same spacing of 2.5 would have to have 8 bins, with the following X axis:
and the |
Most of the links from the above discussion are broken so here are equivalent links: |
Using the test.dx.gz file:
# OpenDX density file written by gridDataFormats.Grid.export()
# File format: http://opendx.sdsc.edu/docs/html/pages/usrgu068.htm#HDREDF
# Data are embedded in the header and tied to the grid positions.
# Data is written in C array order: In grid[x,y,z] the axis z is fastest
# varying, then y, then finally x, i.e. z is the innermost loop.
# (Note: the VMD dx-reader chokes on comments below this line)
object 1 class gridpositions counts 2 2 2
origin 20.100000 3.000000 -10.000000
delta 1.000000 0.000000 0.000000
delta 0.000000 1.000000 0.000000
delta 0.000000 0.000000 1.000000
object 2 class gridconnections counts 2 2 2
object 3 class array type "double" rank 0 items 8 data follows
1.000000000000000 1.000000000000000 1.000000000000000
1.000000000000000 0.000001000000000 -1000000.000000000000000
1.000000000000000 1.000000000000000
attribute "dep" string "positions"
object "density" class field
component "positions" value 1
component "connections" value 2
component "data" value 3
The coordinates of the first center are the same coordinates of the origin.
I think that all the coordinates for the centers should be displaced (self.delta * 0.5). This is right or I misinterpreted the function?
The text was updated successfully, but these errors were encountered: