Thread: Re: [apbs-users] Strict grid control problems
Biomolecular electrostatics software
Brought to you by:
sobolevnrm
From: Robert K. <ro...@uc...> - 2013-04-02 20:26:27
|
Hi Jesper, looking at the code it seem there is a bug/feature :) which resets dime for all even c's (in c*2^VMGNLEV + 1). Nathan might comment on this. Robert On Tue, Apr 02, 2013 at 11:57:56AM -0700, Jesper Sørensen wrote: > Hi Robert, > > I've run the tool and the 113 verts/directions is a correct option: > > 113 verts/direction => 4 levels > 7 verts on coarsest level > ~220.169 MB memory (for 113^3 mesh) > > So this comes back to my original problem that APBS re-dimes me when I use this option: > > > I thought I could do this by using the "dime" keyword, but APBS keeps > > forcing a re-dime: > > NOsh: Bad dime[0] = 113 (3 nlev)! > > NOsh: Reset dime[0] to 97 and (nlev = 4). > > Any suggestions? > > Best, > Jesper > > > > On Apr 2, 2013, at 11:54 AM, Robert Konecny <ro...@uc...> wrote: > > > Hi Jesper, > > > > tools/mesh/mgmesh will print for you all allowed combinations of nlev and > > number of grid points: > > > > # apbs/tools/mesh/mgmesh > > > > This program determines the acceptable meshpoint number > > and level combinations for the PMG multigrid libraries and > > 4 or more levels in the mesh (because you typically use > > one less than the max number of levels) > > > > > > 17 verts/direction => 4 levels > > 1 verts on coarsest level > > ~0.749664 MB memory (for 17^3 mesh) > > 33 verts/direction => 5 levels > > 1 verts on coarsest level > > ~5.48355 MB memory (for 33^3 mesh) > > 49 verts/direction => 4 levels > > 3 verts on coarsest level > > ~17.9518 MB memory (for 49^3 mesh) > > 65 verts/direction => 6 levels > > 1 verts on coarsest level > > ~41.9044 MB memory (for 65^3 mesh) > > > > ... > > > > Best, > > > > Robert > > > > On Tue, Apr 02, 2013 at 11:39:45AM -0700, Jesper Soerensen wrote: > >> Hi Patrizio, > >> > >> My code reading skills aren't the greatest, so I want to make sure I > >> understand this right. > >> > >> nlev (l) has a max of 4? and if it is higher it gets reset? > >> > >> But then for my 113 where nlev is 3 I should be good, although c=7 for > >> that. Is there a max on "c" as well? > >> > >> Or is there a ratio relationship between the two that I can't read from > >> the code? > >> > >> Best, > >> > >> Jesper > >> > >> On Tuesday, April 2, 2013 1:30:52 AM UTC-7, patrizio ansalone wrote: > >> > >> In the apbs programmer guide: [1]http://sourceforge.net/ > >> projects/apbs/files/apbs/apbs-1.4.0/APBS-1.4-programmer_ > >> guide.tar.gz/download > >> 1. at pg 106: > >> + file vhal.h Contains generic macro definitions for APBS also > >> the VMGNLEV . > >> 2. if you read the programmer.pdf at page 531: > >> > >> /* Weâd like to have at least VMGNLEV levels in the multigrid > >> > >> 00292 * hierarchy. This means that the dimension needs to be > >> > >> 00293 * c*2^VMGNLEV + 1, where c is an integer. */ > >> > >> 00294 if ((tdime[i] > 65) && (tnlev[i] < VMGNLEV)) { > >> > >> 00295 Vnm_print(2, "NOsh: Bad dime[%d] = %d (%d nlev)!nn", > >> > >> Vnm_print(2, "NOsh: Bad dime[%d] = %d (%d nlev)!nn", > >> 00296 i, tdime[i], tnlev[i]); > >> 00297 ti = (int)(tdime[i]/VPOW(2.,(VMGNLEV+1))); > >> 00298 if (ti < 1) ti = 1; > >> 00299 tdime[i] = ti*(int)(VPOW(2.,(VMGNLEV+1))) + 1; > >> 00300 tnlev[i] = 4; > >> Vnm_print(2, "NOsh: Reset dime[%d] to %d and (nlev = %d). > >> nn", i, tdime[i], VMGNLEV); > >> > >> Patrizio > >> > >> On Tue, Apr 2, 2013 at 12:38 AM, Jesper Soerensen > >> <[2]jesor...@ucsd.edu> wrote: > >> > >> Hi again, > >> > >> The thing is that 113 does fit in the nx=... formula with c=7 and l=3 > >> and that is why it confuses me that APBS chooses to re-dime my > >> calculation automatically. Any ideas here? > >> > >> Are there max "c" or "l" values that I should stay within to avoid this > >> problem? > >> > >> NOsh: Bad dime[0] = 113 (3 nlev)! > >> NOsh: Reset dime[0] to 97 and (nlev = 4). > >> > >> Best regards, > >> > >> Jesper > >> > >> On Monday, April 1, 2013 12:07:05 PM UTC-7, patrizio ansalone wrote: > >> > >> On Mon, Apr 1, 2013 at 6:45 PM, Jesper Soerensen <jesor...@ucsd.edu> > >> wrote: > >> > >> Hi Patrizio, > >> > >> Thanks for the response. It doesn't really help with my current > >> problem, because I can't set the nlev=5 in an mg-manual calculation, as > >> this is a deprecated keyword. > >> > >> Probably Nathan can answer better then me to this question. I think > >> that you do not need to set the nlev. In the previous example you fix > >> the number of points in the grid box with the "dime nx ny nz" and the > >> spacing "grid hx hy hz" then apbs internally compute the nlev value. > >> > >> Secondly, I am using the grid keyword as described, yet I still need to > >> control the size of the grid not just the spacing. > >> > >> > >> you can substitute the keyword grid with glen > >> example: > >> glen 50 50 50 > >> > >> I need a solution for an Mg-manual calculation to control both of these > >> parameters. > >> > >> In terms of the nx=c*2^(l+1)+1, what value do you use for the "c" > >> constant? > >> > >> I think that you have two choices: > >> 1. fix the grid spacing grid hx hy hz and fix a number of points dime > >> nx ny nz such that nx*hx ny*hy nz*hz are sufficiently large to > >> bound the whole protein. > >> 2. fix the "glen Lx Ly Lz" (bounding box sufficiently large tu cover > >> the whole protein) and than fix a number of points "dime nx ny" nz |
From: Baker, N. <Nat...@pn...> - 2013-04-04 00:29:54
|
Is it bug? If c is even, then another multiple of 2 can be factored out and added to the effective number of levels. Thanks, -- Nathan Baker Pacific Northwest National Laboratory Phone: +1-509-375-3997 http://nabaker.me On 4/2/13 12:51 PM, "Robert Konecny" <ro...@uc...> wrote: >Hi Jesper, > >looking at the code it seem there is a bug/feature :) which resets dime >for >all even c's (in c*2^VMGNLEV + 1). Nathan might comment on this. > >Robert > >On Tue, Apr 02, 2013 at 11:57:56AM -0700, Jesper Sørensen wrote: >> Hi Robert, >> >> I've run the tool and the 113 verts/directions is a correct option: >> >> 113 verts/direction => 4 levels >> 7 verts on coarsest level >> ~220.169 MB memory (for 113^3 mesh) >> >> So this comes back to my original problem that APBS re-dimes me when I >>use this option: >> >> > I thought I could do this by using the "dime" keyword, but APBS >>keeps >> > forcing a re-dime: >> > NOsh: Bad dime[0] = 113 (3 nlev)! >> > NOsh: Reset dime[0] to 97 and (nlev = 4). >> >> Any suggestions? >> >> Best, >> Jesper >> >> >> >> On Apr 2, 2013, at 11:54 AM, Robert Konecny <ro...@uc...> wrote: >> >> > Hi Jesper, >> > >> > tools/mesh/mgmesh will print for you all allowed combinations of nlev >>and >> > number of grid points: >> > >> > # apbs/tools/mesh/mgmesh >> > >> > This program determines the acceptable meshpoint number >> > and level combinations for the PMG multigrid libraries and >> > 4 or more levels in the mesh (because you typically use >> > one less than the max number of levels) >> > >> > >> > 17 verts/direction => 4 levels >> > 1 verts on coarsest level >> > ~0.749664 MB memory (for 17^3 mesh) >> > 33 verts/direction => 5 levels >> > 1 verts on coarsest level >> > ~5.48355 MB memory (for 33^3 mesh) >> > 49 verts/direction => 4 levels >> > 3 verts on coarsest level >> > ~17.9518 MB memory (for 49^3 mesh) >> > 65 verts/direction => 6 levels >> > 1 verts on coarsest level >> > ~41.9044 MB memory (for 65^3 mesh) >> > >> > ... >> > >> > Best, >> > >> > Robert >> > >> > On Tue, Apr 02, 2013 at 11:39:45AM -0700, Jesper Soerensen wrote: >> >> Hi Patrizio, >> >> >> >> My code reading skills aren't the greatest, so I want to make sure >>I >> >> understand this right. >> >> >> >> nlev (l) has a max of 4? and if it is higher it gets reset? >> >> >> >> But then for my 113 where nlev is 3 I should be good, although c=7 >>for >> >> that. Is there a max on "c" as well? >> >> >> >> Or is there a ratio relationship between the two that I can't read >>from >> >> the code? >> >> >> >> Best, >> >> >> >> Jesper >> >> >> >> On Tuesday, April 2, 2013 1:30:52 AM UTC-7, patrizio ansalone >>wrote: >> >> >> >> In the apbs programmer guide: [1]http://sourceforge.net/ >> >> projects/apbs/files/apbs/apbs-1.4.0/APBS-1.4-programmer_ >> >> guide.tar.gz/download >> >> 1. at pg 106: >> >> + file vhal.h Contains generic macro definitions for APBS >>also >> >> the VMGNLEV . >> >> 2. if you read the programmer.pdf at page 531: >> >> >> >> /* Weâd like to have at least VMGNLEV levels in the multigrid >> >> >> >> 00292 * hierarchy. This means that the dimension needs to be >> >> >> >> 00293 * c*2^VMGNLEV + 1, where c is an integer. */ >> >> >> >> 00294 if ((tdime[i] > 65) && (tnlev[i] < VMGNLEV)) { >> >> >> >> 00295 Vnm_print(2, "NOsh: Bad dime[%d] = %d (%d nlev)!nn", >> >> >> >> Vnm_print(2, "NOsh: Bad dime[%d] = %d (%d nlev)!nn", >> >> 00296 i, tdime[i], tnlev[i]); >> >> 00297 ti = (int)(tdime[i]/VPOW(2.,(VMGNLEV+1))); >> >> 00298 if (ti < 1) ti = 1; >> >> 00299 tdime[i] = ti*(int)(VPOW(2.,(VMGNLEV+1))) + 1; >> >> 00300 tnlev[i] = 4; >> >> Vnm_print(2, "NOsh: Reset dime[%d] to %d and (nlev = %d). >> >> nn", i, tdime[i], VMGNLEV); >> >> >> >> Patrizio >> >> >> >> On Tue, Apr 2, 2013 at 12:38 AM, Jesper Soerensen >> >> <[2]jesor...@ucsd.edu> wrote: >> >> >> >> Hi again, >> >> >> >> The thing is that 113 does fit in the nx=... formula with c=7 and >>l=3 >> >> and that is why it confuses me that APBS chooses to re-dime my >> >> calculation automatically. Any ideas here? >> >> >> >> Are there max "c" or "l" values that I should stay within to avoid >>this >> >> problem? >> >> >> >> NOsh: Bad dime[0] = 113 (3 nlev)! >> >> NOsh: Reset dime[0] to 97 and (nlev = 4). >> >> >> >> Best regards, >> >> >> >> Jesper >> >> >> >> On Monday, April 1, 2013 12:07:05 PM UTC-7, patrizio ansalone >>wrote: >> >> >> >> On Mon, Apr 1, 2013 at 6:45 PM, Jesper Soerensen >><jesor...@ucsd.edu> >> >> wrote: >> >> >> >> Hi Patrizio, >> >> >> >> Thanks for the response. It doesn't really help with my current >> >> problem, because I can't set the nlev=5 in an mg-manual >>calculation, as >> >> this is a deprecated keyword. >> >> >> >> Probably Nathan can answer better then me to this question. I think >> >> that you do not need to set the nlev. In the previous example you >>fix >> >> the number of points in the grid box with the "dime nx ny nz" and >>the >> >> spacing "grid hx hy hz" then apbs internally compute the nlev >>value. >> >> >> >> Secondly, I am using the grid keyword as described, yet I still >>need to >> >> control the size of the grid not just the spacing. >> >> >> >> >> >> you can substitute the keyword grid with glen >> >> example: >> >> glen 50 50 50 >> >> >> >> I need a solution for an Mg-manual calculation to control both of >>these >> >> parameters. >> >> >> >> In terms of the nx=c*2^(l+1)+1, what value do you use for the "c" >> >> constant? >> >> >> >> I think that you have two choices: >> >> 1. fix the grid spacing grid hx hy hz and fix a number of points >>dime >> >> nx ny nz such that nx*hx ny*hy nz*hz are sufficiently large to >> >> bound the whole protein. >> >> 2. fix the "glen Lx Ly Lz" (bounding box sufficiently large tu >>cover >> >> the whole protein) and than fix a number of points "dime nx >>ny" nz > >-------------------------------------------------------------------------- >---- >Minimize network downtime and maximize team effectiveness. >Reduce network management and security costs.Learn how to hire >the most talented Cisco Certified professionals. Visit the >Employer Resources Portal >http://www.cisco.com/web/learning/employer_resources/index.html >_______________________________________________ >apbs-users mailing list >apb...@li... >https://lists.sourceforge.net/lists/listinfo/apbs-users |