Strict grid control problems

[Jesper Soerensen]

Hello,

I'm trying some mg-manual calculations where I am varying the grid resolution by the keyword "grid".

E.g.

grid 1.0 1.0 1.0 or  grid 0.5 0.5 0.5 or ...

At the same time I want to force the grid to be a certain size, effectively enforcing the "buffer"size around the solute.

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).

Is there a way to work around this? I also tried to change the nlev keyword, but this is now a deprecated keyword.

Any suggestions?

Best,

Jesper

[patrizio ansalone]

If you use mg-auto you can use dime nx ny nz  with nx=c*2^(l+1)+1 (also for ny and nz) then in your case dime 129 129 129 should work with l=5. In this case you could not fix exactly the grid spacing but it depends on  cglen and  fglen. If you use mg-manually you have to use the following keyword grid  (http://www.poissonboltzmann.org/apbs/user-guide/running-apbs/input-files/elec-input-file-section/elec-keywords/grid)  and fix the grid spacings in the x-, y-, and z-directions:

# READ IN MOLECULES

read                                                

    mol pqr born-ion.pqr

end

# COMPUTE POTENTIAL FOR SOLVATED STATE

elec name solvated-coarse

    mg-manual      

    dime 65 65 65

    grid 1.0 1.0 1.0

    gcent mol 1

    mol 1

    lpbe

    bcfl sdh

    pdie 1.0

    sdie 78.54

    chgm spl2

    srfm mol

    srad 1.4

    swin 0.3

    sdens 10.0

    temp 298.15

    calcenergy total

    calcforce no

    write pot dx born-pot-coarse-sol

end

elec name solvated-fine

    mg-manual      

    dime 65 65 65

    grid 0.5 0.5 0.5

    gcent mol 1

    mol 1

    lpbe

    bcfl focus

    pdie 1.0

    sdie 78.54

    chgm spl2

    srfm mol

    srad 1.4

    swin 0.3

    sdens 10.0

    temp 298.15

    calcenergy total

    calcforce no

end

# COMPUTE POTENTIAL FOR REFERENCE STATE

elec name reference-coarse

    mg-manual

    dime 65 65 65

    grid 1.0 1.0 1.0    

    gcent mol 1

    mol 1

    lpbe

    bcfl sdh

    pdie 1.0

    sdie 1.0

    chgm spl2

    srfm mol

    srad 1.4

    swin 0.3

    sdens 10.0

    temp 298.15

    calcenergy total

    calcforce no

    write pot dx born-pot-coarse-ref

end

elec name reference-fine

    mg-manual

    dime 65 65 65

    grid 0.5 0.5 0.5

    gcent mol 1

    mol 1

    lpbe

    bcfl focus

    pdie 1.0

    sdie 1.0

    chgm spl2

    srfm mol

    srad 1.4

    swin 0.3

    sdens 10.0

    temp 298.15

    calcenergy total

    calcforce no

end

# COMBINE TO GIVE SOLVATION ENERGY

print elecEnergy solvated-fine - reference-fine end

print elecEnergy solvated-fine end

print elecEnergy reference-fine end

quit

Hope this helps

Patrizio  

------------------------------------------------------------------------------
Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
_______________________________________________
apbs-users mailing list
apbs-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/apbs-users

--
You received this message because you are subscribed to the Google Groups "APBS users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to apbs-users+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
---------------------------------------------------------------------------
Patrizio Ansalone
Postdoc in "Computational Biology"
Dip. Elettromagnetismo
I.N.RI.M. - Istituto Nazionale di Ricerca Metrologica
Strada delle Cacce, 91 - 10135
Torino, ITALY
e-mail: p.ans...@inrim.it
---------------------------------------------------------------------------

[Jesper Soerensen]

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. Secondly, I am using the grid keyword as described, yet I still need to control the size of the grid not just the spacing.

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?

Best regards,

Jesper

[patrizio ansalone]

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.

In both cases l and c integers  should be computed internally  in apbs.

Patrizio

P.S.

These are a subset of possible values of dime taking into account the constraint nx=c*2^(l+1)+1

nx(c,l)=

      5      9    17    33    65

      9    17    33    65   129

    13    25    49    97   193

    17    33    65   129   257

    21    41    81   161   321

[Jesper Soerensen]

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

[patrizio ansalone]

In the apbs programmer guide: 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

[Jesper Soerensen]

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

[Jesper Sørensen]

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 <r...@ucsd.edu> 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

>> 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.
>>
>> In both cases l and c integers should be computed internally in apbs.
>> Patrizio
>> P.S.
>> These are a subset of possible values of dime taking into account the
>> constraint nx=c*2^(l+1)+1
>> nx(c,l)=
>> 5 9 17 33 65
>> 9 17 33 65 129
>> 13 25 49 97 193
>> 17 33 65 129 257
>> 21 41 81 161 321
>>
>> Best regards,
>>
>> Jesper
>>
>> On Monday, April 1, 2013 9:22:34 AM UTC-7, patrizio ansalone wrote:
>>
>> If you use mg-auto you can use dime nx ny nz with nx=c*2^(l+1)+1 (also
>> for ny and nz) then in your case dime 129 129 129 should work with l=5.
>> In this case you could not fix exactly the grid spacing but it depends
>> on cglen and fglen. If you use mg-manually you have to use the

>> following keyword grid ([3]http://www.poissonboltzmann.
>> org/apbs/user-guide/running-apbs/input-files/elec-input-file

>> Submit your demo by 6/6/13. [4]http://p.sf.net/sfu/intel_levelupd2d

>> _______________________________________________
>> apbs-users mailing list
>>
>> apbs-...@lists.sourceforge.net
>>

>> [5]https://lists.sourceforge.net/lists/listinfo/apbs-users

>> --
>> You received this message because you are subscribed to the Google
>> Groups "APBS users" group.
>>
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to apbs-users+...@googlegroups.com.
>>

>> For more options, visit [6]https://groups.google.com/groups/opt_out.
>>
>> --
>> ------------------------------------------------------------
>> ---------------

>> e-mail: [7]p.ans...@inrim.it
>> ------------------------------------------------------------
>> ---------------
>>
>> References
>>
>> 1. http://sourceforge.net/projects/apbs/files/apbs/apbs-1.4.0/APBS-1.4-programmer_guide.tar.gz/download
>> 2. javascript:/
>> 3. http://www.poissonboltzmann.org/apbs/user-guide/running-apbs/input-files/elec-input-file-section/elec-keywords/grid
>> 4. http://p.sf.net/sfu/intel_levelupd2d
>> 5. https://lists.sourceforge.net/lists/listinfo/apbs-users
>> 6. https://groups.google.com/groups/opt_out
>> 7. javascript:/
>
>> ------------------------------------------------------------------------------
>> 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

[Robert Konecny]

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

[Jesper Sørensen]

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?

Best,
Jesper

[Robert Konecny]

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

[Jesper Sørensen]

Okay, let me test this out by picking the next dime up that has nlev=>4. I'll let you know of this works.

Thanks,
Jesper

> --
> 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+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Baker, Nathan]

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

[Baker, Nathan]

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

[Jesper Sørensen]

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

> --
> 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+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Hector A. Baldoni]

unsuscribe

[Giulia]

[Shruti Rao]

unsubscribe

--

Shruti Rao

Research Associate

Innovation Center for Biomedical Informatics (ICBI)

Georgetown University Medical Center

2115 Wisconsin Ave NW, Suite 110

Washington, DC 20007

Office: (202) 687-1096

http://icbi.georgetown.edu/

[Poulami Samai]

[Agustina Ziliani]

unsuscribe

[[INSERM] OUHAMMOUCH Mohamed]

unsuscribe

 

---

Ce message et toutes les pieces jointes (ci-apres "le message") sont confidentiels et sont adresses a l'attention exclusive de ses destinataires. Toute divulgation, utilisation, diffusion ou reproduction (totale ou partielle) du message, ou des informations qu'il contient, doit etre prealablement autorisee par l'expediteur. Tout message electronique est susceptible d'alteration et son integrite ne peut etre assuree. Le Laboratoire francais du Fractionnement des Biotechnologies (LFB) decline toute responsabilite au titre de ce message s'il a ete modifie ou falsifie. Si vous n'etes pas destinataire de ce message, merci de le detruire immediatement et d'avertir l'expediteur de l'erreur de distribution et de la destruction du message.

This e-mail and all the enclosures (hereafter "the message") are confidential and are addressed to the exclusive attention of its recipients. Any disclosure, use, diffusion or reproduction (either whole or partial) of the message, or information which it contains, must be authorized beforehand by the sender. E-mails are susceptible to alteration and their integrity cannot be guaranteed. The Laboratoire francais du Fractionnement et des Biotechnologies (LFB) declines any responsibility under this message if it were modified or falsified. If you are not the intended recipient of this message, please delete it immediately from your system and notify the sender of the wrong delivery and the mail deletion.

[Cintia Jozefkowicz]

unsuscribe

-- 

Bioq. Cintia Jozefkowicz
Departamento de Biodiversidad y Biologia Experimental - CONICET
Facultad de Ciencias Exactas y Naturales
Universidad de Buenos Aires
Pabellon II Ciudad Universitaria
C1426EHA Buenos Aires - Argentina  

cintia...@gmail.com

2013/4/4 [INSERM] OUHAMMOUCH Mohamed <inserm-ou...@lfb.fr>

[Nguyen, Quoc Hung]

unsubscribe

 

---

From: Agustina Ziliani [mailto:agustin...@gmail.com]
Sent: Thursday, April 04, 2013 4:21 PM
To: Shruti Rao
Cc: apbs-...@googlegroups.com; Giulia; apbs-...@lists.sourceforge.net
Subject: Re: [apbs-users] unsuscribe

[Baker, Nathan]

Please do not post unsubscribe requests to the list. You can unsubscribe
yourself via the web form at
https://lists.sourceforge.net/lists/listinfo/apbs-users or you can contact
me directly and I will unsubscribe you.

Thank you,

--
Nathan Baker
Pacific Northwest National Laboratory
Phone: +1-509-375-3997
http://nabaker.me

On 4/4/13 7:03 AM, "Poulami Samai" <psa...@mail.rockefeller.edu> wrote:

>unsuscribe
>--------------------------------------------------------------------------

[adrian...@gmail.com]

Not sure if it makes a difference, but it might...

Sent from my iPhone