## Re: [apbs-users] Strict grid control problems

 Re: [apbs-users] Strict grid control problems From: Jesper Sørensen - 2013-04-04 03:43:06 ```Hi Nathan, Thanks for the reply. That makes a lot of sense and going above nlev=3 fixes my problem - so back to running calculations. Best, Jesper On Apr 3, 2013, at 5:27 PM, "Baker, Nathan" wrote: > Hi All -- > > We restrict nlev < 4 to help reduce memory overhead. Smaller nlev values > can result in very large coarse-level multi grid calculations. Since > these are dense matrix calculations, they can require significant memory. > > Thanks, > > -- > Nathan Baker > Pacific Northwest National Laboratory > Phone: +1-509-375-3997 > http://nabaker.me > > > > > > On 4/2/13 2:41 PM, "Robert Konecny" wrote: > >> On Tue, Apr 02, 2013 at 02:20:59PM -0700, Jesper Sørensen wrote: >>> Ah that is interesting. Yeah it'd be nice to know what the motivation >>> is >>> for this. I mean I can circumvent this I guess by specifying an even >>> larger grid, but it'd be nice to avoid a larger grid. >>> >>> Also, if I use the formula I get that 113 comes from nlev=3,c=7, yet >>> "mgmesh" says it's 4 levels and 7 verts, so we maybe agree of the "c", >>> but not the "l" value, or am I understanding the correlation wrong? >> >> I believe mgmesh is reporting nlev+1. I think the reason behind all this, >> not allowing nlev < 4, is to maintain the accuracy of calculations. >> >> BTW, in my previous email I meant to say that all _odd_ c's cause the >> dime >> resets. >> >> Best, >> >> Robert >> >>> >>> Best, >>> Jesper >>> >>> On Apr 2, 2013, at 12:51 PM, Robert Konecny 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 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...@...> 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 >>> >>>>>>> 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 >> apbs-users@... >> https://lists.sourceforge.net/lists/listinfo/apbs-users > > > ------------------------------------------------------------------------------ > 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 > apbs-users@... > https://lists.sourceforge.net/lists/listinfo/apbs-users > > -- > You received this message because you are subscribed to a topic in the Google Groups "APBS users" group. > To unsubscribe from this topic, visit https://groups.google.com/d/topic/apbs-users/sfo1Rek4ZPU/unsubscribe?hl=en. > To unsubscribe from this group and all its topics, send an email to apbs-users+unsubscribe@... > For more options, visit https://groups.google.com/groups/opt_out. > > ```