You can subscribe to this list here.
2003 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}
(2) 
_{Oct}
(2) 
_{Nov}
(27) 
_{Dec}
(31) 

2004 
_{Jan}
(6) 
_{Feb}
(15) 
_{Mar}
(33) 
_{Apr}
(10) 
_{May}
(46) 
_{Jun}
(11) 
_{Jul}
(21) 
_{Aug}
(15) 
_{Sep}
(13) 
_{Oct}
(23) 
_{Nov}
(1) 
_{Dec}
(8) 
2005 
_{Jan}
(27) 
_{Feb}
(57) 
_{Mar}
(86) 
_{Apr}
(23) 
_{May}
(37) 
_{Jun}
(34) 
_{Jul}
(24) 
_{Aug}
(17) 
_{Sep}
(50) 
_{Oct}
(24) 
_{Nov}
(10) 
_{Dec}
(60) 
2006 
_{Jan}
(47) 
_{Feb}
(46) 
_{Mar}
(127) 
_{Apr}
(19) 
_{May}
(26) 
_{Jun}
(62) 
_{Jul}
(47) 
_{Aug}
(51) 
_{Sep}
(61) 
_{Oct}
(42) 
_{Nov}
(50) 
_{Dec}
(33) 
2007 
_{Jan}
(60) 
_{Feb}
(55) 
_{Mar}
(77) 
_{Apr}
(102) 
_{May}
(82) 
_{Jun}
(102) 
_{Jul}
(169) 
_{Aug}
(117) 
_{Sep}
(80) 
_{Oct}
(37) 
_{Nov}
(51) 
_{Dec}
(43) 
2008 
_{Jan}
(71) 
_{Feb}
(94) 
_{Mar}
(98) 
_{Apr}
(125) 
_{May}
(54) 
_{Jun}
(119) 
_{Jul}
(60) 
_{Aug}
(111) 
_{Sep}
(118) 
_{Oct}
(125) 
_{Nov}
(119) 
_{Dec}
(94) 
2009 
_{Jan}
(109) 
_{Feb}
(38) 
_{Mar}
(93) 
_{Apr}
(88) 
_{May}
(29) 
_{Jun}
(57) 
_{Jul}
(53) 
_{Aug}
(48) 
_{Sep}
(68) 
_{Oct}
(151) 
_{Nov}
(23) 
_{Dec}
(35) 
2010 
_{Jan}
(84) 
_{Feb}
(60) 
_{Mar}
(184) 
_{Apr}
(112) 
_{May}
(60) 
_{Jun}
(90) 
_{Jul}
(23) 
_{Aug}
(70) 
_{Sep}
(119) 
_{Oct}
(27) 
_{Nov}
(47) 
_{Dec}
(54) 
2011 
_{Jan}
(22) 
_{Feb}
(19) 
_{Mar}
(92) 
_{Apr}
(93) 
_{May}
(35) 
_{Jun}
(91) 
_{Jul}
(32) 
_{Aug}
(61) 
_{Sep}
(7) 
_{Oct}
(69) 
_{Nov}
(81) 
_{Dec}
(23) 
2012 
_{Jan}
(64) 
_{Feb}
(95) 
_{Mar}
(35) 
_{Apr}
(36) 
_{May}
(63) 
_{Jun}
(98) 
_{Jul}
(70) 
_{Aug}
(171) 
_{Sep}
(149) 
_{Oct}
(64) 
_{Nov}
(67) 
_{Dec}
(126) 
2013 
_{Jan}
(108) 
_{Feb}
(104) 
_{Mar}
(171) 
_{Apr}
(133) 
_{May}
(108) 
_{Jun}
(100) 
_{Jul}
(93) 
_{Aug}
(126) 
_{Sep}
(74) 
_{Oct}
(59) 
_{Nov}
(145) 
_{Dec}
(93) 
2014 
_{Jan}
(38) 
_{Feb}
(45) 
_{Mar}
(26) 
_{Apr}
(41) 
_{May}
(125) 
_{Jun}
(70) 
_{Jul}
(61) 
_{Aug}
(66) 
_{Sep}
(60) 
_{Oct}
(110) 
_{Nov}
(27) 
_{Dec}
(30) 
2015 
_{Jan}
(43) 
_{Feb}
(67) 
_{Mar}
(71) 
_{Apr}
(92) 
_{May}
(39) 
_{Jun}
(15) 
_{Jul}
(46) 
_{Aug}
(63) 
_{Sep}
(15) 
_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 






1
(5) 
2

3

4

5

6
(12) 
7

8

9
(2) 
10

11
(1) 
12
(16) 
13
(23) 
14
(7) 
15
(10) 
16
(1) 
17

18
(14) 
19
(9) 
20
(2) 
21
(7) 
22
(2) 
23
(5) 
24

25
(17) 
26
(9) 
27

28

29

30
(3) 
From: tong giang <metallica1811@ya...>  20131130 20:18:43

Hi all, i'm trying to install libmesh with petsc 3.4.3 and slepc 3.4.3 and get some errors by running make file in libmesh directory. i have dowloaded petsc 3.4.3 and slepc 3.4.3 from its website and installed it successfully in the directory "libmesh/contrib/". Afterward by running the make file of libmesh i got following errors: Make.common:306: /home/giang/libmesh/contrib/slepc3.4.3/bmake/archlinux2cdebug/packages: no file or directory exists Make.common:357: /home/giang/libmesh/contrib/petsc3.4.3/bmake/archlinux2cdebug/packages: no file or directory exists it seems to be some problems of version 3.4.3, because in the slepc3.4.3 or petsc3.4.3 there exists no directory named "bmake". I would appreciate any suggestion and thank you in advance. Regards, Giang 
From: Subramanya Sadasiva <potaman@ou...>  20131130 16:32:39

Hi, Do you guys know of any free tools that help debug memory errors in parallel code? Essentially a free version of totalview? Thanks, Subramanya 
From: Manav Bhatia <bhatiamanav@gm...>  20131130 14:34:21

Hi, I am trying to understand the hpselection (coarsen) strategy currently in libMesh. My current reference is Demkowicz’s book: Computing with hpAdaptive Finite Elements, which uses projections from a fine mesh solution onto a coarse mesh to identify rate of error reduction using h or p refinements. Is the strategy in the code through coarsentest similar to that? While looking through the code, it seemed like the current mesh solution is treated as the fine solution and projected onto h or p coarsening to identify rate of error reduction, and this rate is used to select between h or p refinement. So, it seems similar in principle, but I would appreciate if someone with more knowledge could comment. Also, is there a reference that describes the strategy currently implemented? Thanks, Manav 
From: Subramanya Sadasiva <potaman@ou...>  20131126 21:09:27

Hi Dmitry, Thanks very much. I will try if that works. Subramanya On Nov 26, 2013, at 4:03 PM, Dmitry Karpeyev <karpeev@...> wrote: > Ah, that might still be true, although that ought to be changed. > In any event, you can use the DM to set the bounds for the VI, > and set up PCFieldSplit as I explained in the previous email. > > Let me know if this works for you. > Cheers, > Dmitry. > > > On Tue, Nov 26, 2013 at 3:01 PM, Subramanya Sadasiva <potaman@...> wrote: > Hi Dmitry, > I was under the impression that I needed to use the DM to use the VI solver. Is that not the case? > Thanks, > Subramanya. > > On Nov 26, 2013, at 3:17 PM, Dmitry Karpeyev <karpeev@...> wrote: > >> I assume you are referring to using the Schurcomplement flavor of PCFieldSplit? >> How many variables do you have? Are they all C0? Is the basis nodal? If so, >> you don't necessarily need DMlibMesh: >> >> Assume you have m P1 variables (maybe m==2?). You can lay your degrees of freedom >> in the variablemajor order (by this I mean having contiguous nodal coefficients corresponding >> to a given node  maybe that's called 'nodemajor':). >> Then use these options: >> pc_type fieldsplit pc_fieldsplit_block_size m pc_fieldsplit_0_fields 0 pc_fieldsplit_1_fields 1\ >> pc_fieldsplit_type schur pc_fieldsplit_schur_factorization_type full >> >> This will put the 0th (in the zerobase Cspeak) variable into the 0th split, and the first variable >> in the first split. You can also permute the column blocks, if necessary, or put more variables >> into each split. You might try pc_fieldsplit_schur_factorization_type upper or lower. >> >> The crucial part, however, is to have a good preconditioner for S, which in the terminology of the notes >> you sent is S = D  C inv(A) B. By default PETSc will use D as the preconditioner for S. That may >> or may not be good enough. Otherwise you will need to assemble a preconditioner for S, things >> will get more hairy, and we might need to put more support for that into libMesh. >> >> Hope this helps. >> Dmitry. >> >> >> On Tue, Nov 26, 2013 at 1:56 PM, Subramanya Sadasiva <potaman@...> wrote: >> >> Hi Dmitry, >> I am using the DM solver to solve a Cahn Hilliard equation using a C0 discretization. I would like to use the preconditioner used in >> >> http://www.mcs.anl.gov/~anitescu/Presentations/2011/anitescu2011SIAMCSEDVI.pdf >> >> >> I have been able to use the PETSCDM solver with the VI solver to solve the Cahn Hilliard equation, but I haven’t been able to get a fieldsplit preconditioner to work. >> >> Thanks, >> Subramanya >> >> >> On Nov 26, 2013, at 2:07 PM, Dmitry Karpeyev <karpeev@...> wrote: >> >>> DMlibMesh should work, but it's in need of an overhaul and simplification. >>> Could you tell me how you intend to use it? That way we can figure out >>> what needs to be done to make it usable. >>> Thanks. >>> Dmitry. >>> >>> >>> On Thu, Nov 21, 2013 at 1:32 PM, subramanya sadasiva <potaman@...> wrote: >>> Hi , I want to use petsc fieldsplit preconditioners with the petscdm solver that has been implemented as part of libmesh. The last time I tried it, I had trouble because dmcreatefielddecomposition was not being called. Is there someone that could guide me with trying to correct this in libmesh? Thanks, Subramanya >>>  >>> Shape the Mobile Experience: Free Subscription >>> Software experts and developers: Be at the forefront of tech innovation. >>> Intel(R) Software Adrenaline delivers strategic insight and gamechanging >>> conversations that shape the rapidly evolving mobile landscape. Sign up now. >>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Libmeshusers mailing list >>> Libmeshusers@... >>> https://lists.sourceforge.net/lists/listinfo/libmeshusers >>> >>> >>> >>>  >>> Dmitry Karpeev >>> Mathematics and Computer Science >>> Argonne National Laboratory >>> Argonne, Illinois, USA >>> and >>> Computation Institute >>> University of Chicago >>> 5735 S. Ellis Avenue >>> Chicago, IL 60637 >>>  >>> Phone: 6302521229 >>> Fax: 6302525986 >> >> >> >> > > > > 
From: Dmitry Karpeyev <karpeev@mc...>  20131126 21:04:45

Ah, that might still be true, although that ought to be changed. In any event, you can use the DM to set the bounds for the VI, and set up PCFieldSplit as I explained in the previous email. Let me know if this works for you. Cheers, Dmitry. On Tue, Nov 26, 2013 at 3:01 PM, Subramanya Sadasiva <potaman@...>wrote: > Hi Dmitry, > I was under the impression that I needed to use the DM to use the VI > solver. Is that not the case? > Thanks, > Subramanya. > > On Nov 26, 2013, at 3:17 PM, Dmitry Karpeyev <karpeev@...> wrote: > > I assume you are referring to using the Schurcomplement flavor of > PCFieldSplit? > How many variables do you have? Are they all C0? Is the basis nodal? If > so, > you don't necessarily need DMlibMesh: > > Assume you have m P1 variables (maybe m==2?). You can lay your degrees of > freedom > in the variablemajor order (by this I mean having contiguous nodal > coefficients corresponding > to a given node  maybe that's called 'nodemajor':). > Then use these options: > pc_type fieldsplit pc_fieldsplit_block_size m pc_fieldsplit_0_fields 0 > pc_fieldsplit_1_fields 1\ > pc_fieldsplit_type schur pc_fieldsplit_schur_factorization_type full > > This will put the 0th (in the zerobase Cspeak) variable into the 0th > split, and the first variable > in the first split. You can also permute the column blocks, if necessary, > or put more variables > into each split. You might try pc_fieldsplit_schur_factorization_type > upper or lower. > > The crucial part, however, is to have a good preconditioner for S, which > in the terminology of the notes > you sent is S = D  C inv(A) B. By default PETSc will use D as the > preconditioner for S. That may > or may not be good enough. Otherwise you will need to assemble a > preconditioner for S, things > will get more hairy, and we might need to put more support for that into > libMesh. > > Hope this helps. > Dmitry. > > > On Tue, Nov 26, 2013 at 1:56 PM, Subramanya Sadasiva <potaman@...>wrote: > >> >> Hi Dmitry, >> I am using the DM solver to solve a Cahn Hilliard equation using a C0 >> discretization. I would like to use the preconditioner used in >> >> >> http://www.mcs.anl.gov/~anitescu/Presentations/2011/anitescu2011SIAMCSEDVI.pdf >> >> >> I have been able to use the PETSCDM solver with the VI solver to solve >> the Cahn Hilliard equation, but I haven’t been able to get a fieldsplit >> preconditioner to work. >> >> Thanks, >> Subramanya >> >> >> On Nov 26, 2013, at 2:07 PM, Dmitry Karpeyev <karpeev@...> wrote: >> >> DMlibMesh should work, but it's in need of an overhaul and simplification. >> Could you tell me how you intend to use it? That way we can figure out >> what needs to be done to make it usable. >> Thanks. >> Dmitry. >> >> >> On Thu, Nov 21, 2013 at 1:32 PM, subramanya sadasiva <potaman@... >> > wrote: >> >>> Hi , I want to use petsc fieldsplit preconditioners with the petscdm >>> solver that has been implemented as part of libmesh. The last time I tried >>> it, I had trouble because dmcreatefielddecomposition was not being called. >>> Is there someone that could guide me with trying to correct this in >>> libmesh? Thanks, Subramanya >>> >>>  >>> Shape the Mobile Experience: Free Subscription >>> Software experts and developers: Be at the forefront of tech innovation. >>> Intel(R) Software Adrenaline delivers strategic insight and gamechanging >>> conversations that shape the rapidly evolving mobile landscape. Sign up >>> now. >>> >>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Libmeshusers mailing list >>> Libmeshusers@... >>> https://lists.sourceforge.net/lists/listinfo/libmeshusers >>> >> >> >> >>  >> Dmitry Karpeev >> Mathematics and Computer Science >> Argonne National Laboratory >> Argonne, Illinois, USA >> and >> Computation Institute >> University of Chicago >> 5735 S. Ellis Avenue >> Chicago, IL 60637 >>  >> Phone: 6302521229 >> Fax: 6302525986 >> >> >> > > > > 
From: Subramanya Sadasiva <potaman@ou...>  20131126 21:01:34

Hi Dmitry, I was under the impression that I needed to use the DM to use the VI solver. Is that not the case? Thanks, Subramanya. On Nov 26, 2013, at 3:17 PM, Dmitry Karpeyev <karpeev@...> wrote: > I assume you are referring to using the Schurcomplement flavor of PCFieldSplit? > How many variables do you have? Are they all C0? Is the basis nodal? If so, > you don't necessarily need DMlibMesh: > > Assume you have m P1 variables (maybe m==2?). You can lay your degrees of freedom > in the variablemajor order (by this I mean having contiguous nodal coefficients corresponding > to a given node  maybe that's called 'nodemajor':). > Then use these options: > pc_type fieldsplit pc_fieldsplit_block_size m pc_fieldsplit_0_fields 0 pc_fieldsplit_1_fields 1\ > pc_fieldsplit_type schur pc_fieldsplit_schur_factorization_type full > > This will put the 0th (in the zerobase Cspeak) variable into the 0th split, and the first variable > in the first split. You can also permute the column blocks, if necessary, or put more variables > into each split. You might try pc_fieldsplit_schur_factorization_type upper or lower. > > The crucial part, however, is to have a good preconditioner for S, which in the terminology of the notes > you sent is S = D  C inv(A) B. By default PETSc will use D as the preconditioner for S. That may > or may not be good enough. Otherwise you will need to assemble a preconditioner for S, things > will get more hairy, and we might need to put more support for that into libMesh. > > Hope this helps. > Dmitry. > > > On Tue, Nov 26, 2013 at 1:56 PM, Subramanya Sadasiva <potaman@...> wrote: > > Hi Dmitry, > I am using the DM solver to solve a Cahn Hilliard equation using a C0 discretization. I would like to use the preconditioner used in > > http://www.mcs.anl.gov/~anitescu/Presentations/2011/anitescu2011SIAMCSEDVI.pdf > > > I have been able to use the PETSCDM solver with the VI solver to solve the Cahn Hilliard equation, but I haven’t been able to get a fieldsplit preconditioner to work. > > Thanks, > Subramanya > > > On Nov 26, 2013, at 2:07 PM, Dmitry Karpeyev <karpeev@...> wrote: > >> DMlibMesh should work, but it's in need of an overhaul and simplification. >> Could you tell me how you intend to use it? That way we can figure out >> what needs to be done to make it usable. >> Thanks. >> Dmitry. >> >> >> On Thu, Nov 21, 2013 at 1:32 PM, subramanya sadasiva <potaman@...> wrote: >> Hi , I want to use petsc fieldsplit preconditioners with the petscdm solver that has been implemented as part of libmesh. The last time I tried it, I had trouble because dmcreatefielddecomposition was not being called. Is there someone that could guide me with trying to correct this in libmesh? Thanks, Subramanya >>  >> Shape the Mobile Experience: Free Subscription >> Software experts and developers: Be at the forefront of tech innovation. >> Intel(R) Software Adrenaline delivers strategic insight and gamechanging >> conversations that shape the rapidly evolving mobile landscape. Sign up now. >> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >> _______________________________________________ >> Libmeshusers mailing list >> Libmeshusers@... >> https://lists.sourceforge.net/lists/listinfo/libmeshusers >> >> >> >>  >> Dmitry Karpeev >> Mathematics and Computer Science >> Argonne National Laboratory >> Argonne, Illinois, USA >> and >> Computation Institute >> University of Chicago >> 5735 S. Ellis Avenue >> Chicago, IL 60637 >>  >> Phone: 6302521229 >> Fax: 6302525986 > > > > 
From: Dmitry Karpeyev <karpeev@mc...>  20131126 20:53:33

Dear All, My apologies in advance for a misuse of this list. However, I wanted to draw your attention to a new postdoctoral position at Argonne National Laboratory, which may be of interest to some of you. This job involves research into efficient algorithms for numerical modeling and simulation of solutions of charged particles in confined geometries. Experience with PETSc, libMesh or MOOSE will be a big plus here, hence, this message. The formal position description can be found here: http://web.anl.gov/jobsearch/detail.jsp?userreqid=321577+MCS&lsBrowse=POSTDOC In plainer terms, however, we are interested in the quantitative understanding of the dynamics of DNA molecules suspended in solutions of varying ionic strength, and confined to channels of 10100nm linear crosssection, with charged walls. If you know your way around FEM models of Stokesian fluids in nontrivial geometries, have experience with electrostatic force calculations, and are interested in making these algorithms run fast, this may be the job for you. We are interested in accelerating these simulations to be able to resolve the longtime fluctuation dynamics of the DNA molecules translocating (i.e., flopping their way through) the nanochannels. Some modeling issues will likely need to be addressed as well: at various ionic strengths the finitesize effects of ions in the solution may become significant near the channel walls or the solute (DNA) molecules. Thus, an interest and experience in particletocontinuum coupling is a plus. A working knowledge of C/C++ is required. Familiarity with the GPU/multicore/manycore architectures is preferred. Experience with the PETSc library (http://www.mcs.anl.gov/petsc) is a huge plus. Ditto libMesh and MOOSE. A successful candidate will work closely with the University of Chicago scientists at the Computation Institute as well as the Institute for Molecular Engineering. If you have questions, please feel free to contact me directly. I apologize, if you are getting this message more than once. Best regards, Dmitry.  Dmitry Karpeyev Mathematics and Computer Science Argonne National Laboratory Argonne, Illinois, USA and Computation Institute University of Chicago 5735 S. Ellis Avenue Chicago, IL 60637  Phone: 6302521229 Fax: 6302525986 
From: Dmitry Karpeyev <karpeev@mc...>  20131126 20:18:21

I assume you are referring to using the Schurcomplement flavor of PCFieldSplit? How many variables do you have? Are they all C0? Is the basis nodal? If so, you don't necessarily need DMlibMesh: Assume you have m P1 variables (maybe m==2?). You can lay your degrees of freedom in the variablemajor order (by this I mean having contiguous nodal coefficients corresponding to a given node  maybe that's called 'nodemajor':). Then use these options: pc_type fieldsplit pc_fieldsplit_block_size m pc_fieldsplit_0_fields 0 pc_fieldsplit_1_fields 1\ pc_fieldsplit_type schur pc_fieldsplit_schur_factorization_type full This will put the 0th (in the zerobase Cspeak) variable into the 0th split, and the first variable in the first split. You can also permute the column blocks, if necessary, or put more variables into each split. You might try pc_fieldsplit_schur_factorization_type upper or lower. The crucial part, however, is to have a good preconditioner for S, which in the terminology of the notes you sent is S = D  C inv(A) B. By default PETSc will use D as the preconditioner for S. That may or may not be good enough. Otherwise you will need to assemble a preconditioner for S, things will get more hairy, and we might need to put more support for that into libMesh. Hope this helps. Dmitry. On Tue, Nov 26, 2013 at 1:56 PM, Subramanya Sadasiva <potaman@...>wrote: > > Hi Dmitry, > I am using the DM solver to solve a Cahn Hilliard equation using a C0 > discretization. I would like to use the preconditioner used in > > > http://www.mcs.anl.gov/~anitescu/Presentations/2011/anitescu2011SIAMCSEDVI.pdf > > > I have been able to use the PETSCDM solver with the VI solver to solve > the Cahn Hilliard equation, but I haven’t been able to get a fieldsplit > preconditioner to work. > > Thanks, > Subramanya > > > On Nov 26, 2013, at 2:07 PM, Dmitry Karpeyev <karpeev@...> wrote: > > DMlibMesh should work, but it's in need of an overhaul and simplification. > Could you tell me how you intend to use it? That way we can figure out > what needs to be done to make it usable. > Thanks. > Dmitry. > > > On Thu, Nov 21, 2013 at 1:32 PM, subramanya sadasiva <potaman@...>wrote: > >> Hi , I want to use petsc fieldsplit preconditioners with the petscdm >> solver that has been implemented as part of libmesh. The last time I tried >> it, I had trouble because dmcreatefielddecomposition was not being called. >> Is there someone that could guide me with trying to correct this in >> libmesh? Thanks, Subramanya >> >>  >> Shape the Mobile Experience: Free Subscription >> Software experts and developers: Be at the forefront of tech innovation. >> Intel(R) Software Adrenaline delivers strategic insight and gamechanging >> conversations that shape the rapidly evolving mobile landscape. Sign up >> now. >> >> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >> _______________________________________________ >> Libmeshusers mailing list >> Libmeshusers@... >> https://lists.sourceforge.net/lists/listinfo/libmeshusers >> > > > >  > Dmitry Karpeev > Mathematics and Computer Science > Argonne National Laboratory > Argonne, Illinois, USA > and > Computation Institute > University of Chicago > 5735 S. Ellis Avenue > Chicago, IL 60637 >  > Phone: 6302521229 > Fax: 6302525986 > > > 
From: Subramanya Sadasiva <potaman@ou...>  20131126 19:56:13

Hi Dmitry, I am using the DM solver to solve a Cahn Hilliard equation using a C0 discretization. I would like to use the preconditioner used in http://www.mcs.anl.gov/~anitescu/Presentations/2011/anitescu2011SIAMCSEDVI.pdf I have been able to use the PETSCDM solver with the VI solver to solve the Cahn Hilliard equation, but I haven’t been able to get a fieldsplit preconditioner to work. Thanks, Subramanya On Nov 26, 2013, at 2:07 PM, Dmitry Karpeyev <karpeev@...> wrote: > DMlibMesh should work, but it's in need of an overhaul and simplification. > Could you tell me how you intend to use it? That way we can figure out > what needs to be done to make it usable. > Thanks. > Dmitry. > > > On Thu, Nov 21, 2013 at 1:32 PM, subramanya sadasiva <potaman@...> wrote: > Hi , I want to use petsc fieldsplit preconditioners with the petscdm solver that has been implemented as part of libmesh. The last time I tried it, I had trouble because dmcreatefielddecomposition was not being called. Is there someone that could guide me with trying to correct this in libmesh? Thanks, Subramanya >  > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech innovation. > Intel(R) Software Adrenaline delivers strategic insight and gamechanging > conversations that shape the rapidly evolving mobile landscape. Sign up now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers > > > >  > Dmitry Karpeev > Mathematics and Computer Science > Argonne National Laboratory > Argonne, Illinois, USA > and > Computation Institute > University of Chicago > 5735 S. Ellis Avenue > Chicago, IL 60637 >  > Phone: 6302521229 > Fax: 6302525986 
From: Derek Gaston <friedmud@gm...>  20131126 19:43:00

On Tue, Nov 26, 2013 at 11:59 AM, Dmitry Karpeyev <karpeev@...>wrote: > LU, naturally, should do better, and we should at least see quicker linear > convergence. > If not, it's an indication that your problem is singular. > LU should only take 1 (ish) linear iteration. However, I still suspect that the issue here is that his Jacobian is wrong... which accounts for the degraded nonlinear convergence. Lorenzo: Have you double checked your Jacobian statements? Have you checked them against your friend doing FEAP? Your statements should look very similar to theirs... Derek 
From: Dmitry Karpeyev <karpeev@mc...>  20131126 19:08:45

DMlibMesh should work, but it's in need of an overhaul and simplification. Could you tell me how you intend to use it? That way we can figure out what needs to be done to make it usable. Thanks. Dmitry. On Thu, Nov 21, 2013 at 1:32 PM, subramanya sadasiva <potaman@...>wrote: > Hi , I want to use petsc fieldsplit preconditioners with the petscdm > solver that has been implemented as part of libmesh. The last time I tried > it, I had trouble because dmcreatefielddecomposition was not being called. > Is there someone that could guide me with trying to correct this in > libmesh? Thanks, Subramanya > >  > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech innovation. > Intel(R) Software Adrenaline delivers strategic insight and gamechanging > conversations that shape the rapidly evolving mobile landscape. Sign up > now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers >  Dmitry Karpeev Mathematics and Computer Science Argonne National Laboratory Argonne, Illinois, USA and Computation Institute University of Chicago 5735 S. Ellis Avenue Chicago, IL 60637  Phone: 6302521229 Fax: 6302525986 
From: Dmitry Karpeyev <karpeev@mc...>  20131126 19:00:06

1. It looks like you are using petsc3.x or older. I would recommend upgrading to petsc3.4, since we don't really maintain earlier versions. 2. Could you run with snes_view so we know exactly what solvers you are using? 3. For a small problem running with pc_type lu, could you post the nonlinear and linear convergence history? snes_monitor ksp_monitor The below convergence history seems to be have been produced with the default solver options, which for the linear solver are ksp_type gmres pc_type ilu. In particular, ILU seems to be a bad preconditioner for this system, but it's not really surprising. LU, naturally, should do better, and we should at least see quicker linear convergence. If not, it's an indication that your problem is singular. Thanks. Dmitry. On Mon, Nov 25, 2013 at 6:23 AM, Lorenzo Zanon <zanon@...>wrote: > Hello, > > Thanks for the detailed answer! > > I've just rerun the executable taking off the snes_mf_operator and LU > options, but it doesn't look any better... : > > Running ./exampleopt snes_type ls snes_linesearch_type basic ksp_rtol > 1e4 > NL step 0, residual_2 = 1.936492e05 > NL step 1, residual_2 = 1.938856e05 > NL step 2, residual_2 = 1.941222e05 > NL step 3, residual_2 = 1.943592e05 > NL step 4, residual_2 = 1.945964e05 > > Then I stopped it because it didn't look like converging, after one hour > or so. > > Monitoring the linear iterations showed: > > Running ./exampleopt ksp_rtol 1e3 ksp_monitor > NL step 0, residual_2 = 1.936492e05 > 0 KSP Residual norm 7.859921803229e07 > 1 KSP Residual norm 3.815524538428e07 > 2 KSP Residual norm 3.364144277753e07 > 3 KSP Residual norm 2.909576661282e07 > 4 KSP Residual norm 2.772044053816e07 > ... > 1654 KSP Residual norm 8.626050416153e10 > 1655 KSP Residual norm 8.145093822144e10 > 1656 KSP Residual norm 6.346659238618e10 > > The same happens with the GAMG options (either pc_gamg_type agg or > pc_gamg_agg_nsmooths 1, from PETSc manual). But I could still reconfigure > PETSc and libMesh with the hypre option. > > I still haven't asked my FEAP colleague about the specifications she's > using, but she told me it takes 4 or 5 nonlinear iterations to converge, > depending on the loading. > > Thanks! > Lorenzo > > On Nov 22, 2013, at 7:10 PM, Derek Gaston wrote: > > > snes_mf_operator is a PETSc option specifying that you want to do > preconditioned Jacobian Free Newton Krylov (JFNK). Is the guy using FEAP > doing JFNK? > > > > JFNK means that every linear iteration inside a Newton step you must > recompute your residual. That means a full sweep over the mesh, > reevaluating your material properties and residual statements at every > quadrature point to assemble a full residual vector. This is expensive. > > > > If you are just doing a single physics problem (and it sounds like you > are) and you have the ability to compute the exact Jacobian (which it > sounds like you do) then using snes_mf_operator will more than likely be > MUCH slower than just solving using Newton's method like normal (where you > assemble a matrix and a RHS just _once_ per Newton step  then throw a > linear solver at it). > > > > To use "regular" Newton just leave that option off. > > > > Further, you have specified "pc_type lu"... which is generally a bad > idea for performance. With LU you are doing a direct inversion of your > Jacobian matrix (oldschool style!) and using it as a preconditioner. It > is generally much better to use an "inexact" Newton formulation where you > don't perfectly invert your Jacobian matrix and instead let your Krylov > solver solve to some (fairly loose) tolerance (ie use ksp_rtol 1e4 or > larger) so that you are not "oversolving" your linear problem inside each > Newton step. > > > > Instead of using LU I highly recommend using an algebraic multigrid > preconditioner for solid mechanics. Look into using GAMG in PETSc or use > downloadhypre when configuring PETSc and use: pc_type hypre > pc_hypre_type boomeramg. > > > > > > Basically: Your solver options are nonoptimal. Make sure you are > solving using _exactly_ the same solver options between libMesh and FEAP > before doing any comparisons. You should probably run with ksp_monitor to > show you how many linear iterations you're taking and then make sure that > both your libMesh and FEAP implementations are taking the same (or VERY > similar) number of both nonlinear _and_ linear iterations > > > > > > Derek > > > > > > > > On Fri, Nov 22, 2013 at 10:08 AM, Lorenzo Zanon < > zanon@...> wrote: > > Hello, > > > > I have an example based on miscellaneous_ex3.C, where I implemented a > nonlinear elastic problem with StVenant stressstrain law on a 3D domain > 5x1x1, blocked at x=0 and with an applied load at x=5. The problem is, the > computation of the displacement (along x y and z) is really slow (hours), > on our cluster it goes out of CPU time already with a mesh of 64x8x1 (the > loading acts only on the ydirection, so no more elements are needed along > z). 4 or 5 Newton steps should be enough for solving the problem... > > > > A colleague of mine implemented the same problem on the software called > FEAP, and it takes only a few minutes there. I think my implementation is > correct because the results on a very coarse mesh (10x2x1) are roughly > similar to the FEAP ones on a finer mesh. I don't have any problems for the > 2D case also. > > > > Is there anything I can do? I'm running in opt mode with the following > options concerning the Newton solver: > > > > snes_type ls snes_linesearch_type basic snes_mf_operator pc_type lu > pc_factor_nonzeros_along_diagonal > > > > Thanks! > > Lorenzo > > >  > > Shape the Mobile Experience: Free Subscription > > Software experts and developers: Be at the forefront of tech innovation. > > Intel(R) Software Adrenaline delivers strategic insight and gamechanging > > conversations that shape the rapidly evolving mobile landscape. Sign up > now. > > > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > > _______________________________________________ > > Libmeshusers mailing list > > Libmeshusers@... > > https://lists.sourceforge.net/lists/listinfo/libmeshusers > > > > >  > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech innovation. > Intel(R) Software Adrenaline delivers strategic insight and gamechanging > conversations that shape the rapidly evolving mobile landscape. Sign up > now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers >  Dmitry Karpeev Mathematics and Computer Science Argonne National Laboratory Argonne, Illinois, USA and Computation Institute University of Chicago 5735 S. Ellis Avenue Chicago, IL 60637  Phone: 6302521229 Fax: 6302525986 
From: Robert <libmesh@ro...>  20131125 22:20:44

Hi, If you don't like deriving the stuff by hand you might have a look at AceGen (http://www.fgg.unilj.si/Symech/), it uses Mathematica for the linarization and generates C code for the residual and jacobian. Robert On Mon, Nov 25, 2013 at 12:01:20PM 0700, Derek Gaston wrote: > If it works with JFNK and fails without it... that means your Jacobian is incorrect. Take another look at your derivatives that are going into your Jacobian... > > Derek > > Sent from my iPhone > > On Nov 25, 2013, at 11:19 AM, Lorenzo Zanon <zanon@...> wrote: > > >> Are you sure the Jacobian is correct? Is this a buckling problem, or > >> something nonsmooth like plasticity or contact? If not, Newton should > >> converge fairly fast. > > > > It should be, running on a 10x2x1 mesh I get convergence and a roughly correct output (wrt FEAP). The problem is just a bar with an applied load, modelled with nonlinear hysotropic elasticity (no plasticity, no contact). > > > >> Did you set a near null space (rigid body modes) using > >> MatSetNearNullSpace and perhaps MatNullSpaceCreateRigidBody? Are you > >> using a nodal basis? How do you enforce boundary conditions? > > > > I'm using Lagrange first order on HEX8 elements. Boundary conditions are set as in the example: > > > > std::set<boundary_id_type> boundary_ids; > > boundary_ids.insert(4); // 3D > > ... > > // Create a ZeroFunction to initialize dirichlet_bc > > ZeroFunction<> zf; > > DirichletBoundary dirichlet_bc(boundary_ids, variables, &zf); > > system.get_dof_map().add_dirichlet_boundary(dirichlet_bc); > > > >> Do you need the line search? with an NL decay rate that slow one of two things is happening I'd bet  either the Jacobian is incorrect, so your computed dU is not a descent direction(see the increase from steps 24) or the line search is behaving nonoptimally. > > > > > > Testing on the small 10x2x1 problem, without any option it fails: > > > >> exampleopt > >> NL step 0, residual_2 = 3.464102e05 > >> StVen system solved at nonlinear iteration 0 , final nonlinear residual norm: 3.464102e05 > > > > With linesearch and JFNK it works: > > > >> exampleopt snes_type ls snes_linesearch_type basic snes_mf_operator > >> NL step 0, residual_2 = 3.464102e05 > >> NL step 1, residual_2 = 2.417673e04 > >> NL step 2, residual_2 = 6.139470e08 > >> NL step 3, residual_2 = 5.468950e13 > >> NL step 4, residual_2 = 7.179521e18 > >> StVen system solved at nonlinear iteration 4 , final nonlinear residual norm: 7.179521e18 > > > > Using either linesearch or JFNK it doesn't converge, it looks like I need both. Apparently I can do without LU, but still it's very slow. > > > > Thanks > > Lorenzo > > > >> On Nov 25, 2013, at 4:01 PM, Kirk, Benjamin (JSCEG311) wrote: > >> > >> > >> On Nov 25, 2013, at 6:23 AM, Lorenzo Zanon <zanon@...> > >> wrote: > >> > >>> Hello, > >>> > >>> Thanks for the detailed answer! > >>> > >>> I've just rerun the executable taking off the snes_mf_operator and LU options, but it doesn't look any better... : > >>> > >>> Running ./exampleopt snes_type ls snes_linesearch_type basic ksp_rtol 1e4 > >>> NL step 0, residual_2 = 1.936492e05 > >>> NL step 1, residual_2 = 1.938856e05 > >>> NL step 2, residual_2 = 1.941222e05 > >>> NL step 3, residual_2 = 1.943592e05 > >>> NL step 4, residual_2 = 1.945964e05 > >>> > >>> Then I stopped it because it didn't look like converging, after one hour or so. > >> > >> Do you need the line search? with an NL decay rate that slow one of two things is happening I'd bet  either the Jacobian is incorrect, so your computed dU is not a descent direction(see the increase from steps 24) or the line search is behaving nonoptimally. > >> > >> I think snes_info (?) will present more verbose information that may be useful to you. > >> > >> Ben > > > > > >  > > Shape the Mobile Experience: Free Subscription > > Software experts and developers: Be at the forefront of tech innovation. > > Intel(R) Software Adrenaline delivers strategic insight and gamechanging > > conversations that shape the rapidly evolving mobile landscape. Sign up now. > > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > > _______________________________________________ > > Libmeshusers mailing list > > Libmeshusers@... > > https://lists.sourceforge.net/lists/listinfo/libmeshusers > >  > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech innovation. > Intel(R) Software Adrenaline delivers strategic insight and gamechanging > conversations that shape the rapidly evolving mobile landscape. Sign up now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers 
From: Derek Gaston <friedmud@gm...>  20131125 19:01:30

If it works with JFNK and fails without it... that means your Jacobian is incorrect. Take another look at your derivatives that are going into your Jacobian... Derek Sent from my iPhone On Nov 25, 2013, at 11:19 AM, Lorenzo Zanon <zanon@...> wrote: >> Are you sure the Jacobian is correct? Is this a buckling problem, or >> something nonsmooth like plasticity or contact? If not, Newton should >> converge fairly fast. > > It should be, running on a 10x2x1 mesh I get convergence and a roughly correct output (wrt FEAP). The problem is just a bar with an applied load, modelled with nonlinear hysotropic elasticity (no plasticity, no contact). > >> Did you set a near null space (rigid body modes) using >> MatSetNearNullSpace and perhaps MatNullSpaceCreateRigidBody? Are you >> using a nodal basis? How do you enforce boundary conditions? > > I'm using Lagrange first order on HEX8 elements. Boundary conditions are set as in the example: > > std::set<boundary_id_type> boundary_ids; > boundary_ids.insert(4); // 3D > ... > // Create a ZeroFunction to initialize dirichlet_bc > ZeroFunction<> zf; > DirichletBoundary dirichlet_bc(boundary_ids, variables, &zf); > system.get_dof_map().add_dirichlet_boundary(dirichlet_bc); > >> Do you need the line search? with an NL decay rate that slow one of two things is happening I'd bet  either the Jacobian is incorrect, so your computed dU is not a descent direction(see the increase from steps 24) or the line search is behaving nonoptimally. > > > Testing on the small 10x2x1 problem, without any option it fails: > >> exampleopt >> NL step 0, residual_2 = 3.464102e05 >> StVen system solved at nonlinear iteration 0 , final nonlinear residual norm: 3.464102e05 > > With linesearch and JFNK it works: > >> exampleopt snes_type ls snes_linesearch_type basic snes_mf_operator >> NL step 0, residual_2 = 3.464102e05 >> NL step 1, residual_2 = 2.417673e04 >> NL step 2, residual_2 = 6.139470e08 >> NL step 3, residual_2 = 5.468950e13 >> NL step 4, residual_2 = 7.179521e18 >> StVen system solved at nonlinear iteration 4 , final nonlinear residual norm: 7.179521e18 > > Using either linesearch or JFNK it doesn't converge, it looks like I need both. Apparently I can do without LU, but still it's very slow. > > Thanks > Lorenzo > >> On Nov 25, 2013, at 4:01 PM, Kirk, Benjamin (JSCEG311) wrote: >> >> >> On Nov 25, 2013, at 6:23 AM, Lorenzo Zanon <zanon@...> >> wrote: >> >>> Hello, >>> >>> Thanks for the detailed answer! >>> >>> I've just rerun the executable taking off the snes_mf_operator and LU options, but it doesn't look any better... : >>> >>> Running ./exampleopt snes_type ls snes_linesearch_type basic ksp_rtol 1e4 >>> NL step 0, residual_2 = 1.936492e05 >>> NL step 1, residual_2 = 1.938856e05 >>> NL step 2, residual_2 = 1.941222e05 >>> NL step 3, residual_2 = 1.943592e05 >>> NL step 4, residual_2 = 1.945964e05 >>> >>> Then I stopped it because it didn't look like converging, after one hour or so. >> >> Do you need the line search? with an NL decay rate that slow one of two things is happening I'd bet  either the Jacobian is incorrect, so your computed dU is not a descent direction(see the increase from steps 24) or the line search is behaving nonoptimally. >> >> I think snes_info (?) will present more verbose information that may be useful to you. >> >> Ben > > >  > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech innovation. > Intel(R) Software Adrenaline delivers strategic insight and gamechanging > conversations that shape the rapidly evolving mobile landscape. Sign up now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers 
From: subramanya sadasiva <potaman@ou...>  20131125 18:57:29

@David, Sorry about the previous message . pressed send while trying to switch from reply to replyall. Thanks. That is useful. Subramanya > Date: Mon, 25 Nov 2013 13:48:41 0500 > From: dknezevic@... > To: libmeshusers@... > Subject: Re: [Libmeshusers] Output partitioning information to exodus_ii files > > I recently asked Cody how he does this at INL, since he forwarded some > nice partition plots to the list :) > > The answer was that they store processor_id() on each element using a > CONSTANT MONOMIAL in an ExplicitSystem. You can then plot the solution > as usual. > > > > > On 11/25/2013 01:45 PM, subramanya sadasiva wrote: > > Hi, is there anyway to see how the mesh has been partitioned in the exodus_ii files?Thanks, Subramanya > > > >  > > Shape the Mobile Experience: Free Subscription > > Software experts and developers: Be at the forefront of tech innovation. > > Intel(R) Software Adrenaline delivers strategic insight and gamechanging > > conversations that shape the rapidly evolving mobile landscape. Sign up now. > > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > > _______________________________________________ > > Libmeshusers mailing list > > Libmeshusers@... > > https://lists.sourceforge.net/lists/listinfo/libmeshusers > > >  > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech innovation. > Intel(R) Software Adrenaline delivers strategic insight and gamechanging > conversations that shape the rapidly evolving mobile landscape. Sign up now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers 
From: David Knezevic <dknezevic@se...>  20131125 18:48:50

I recently asked Cody how he does this at INL, since he forwarded some nice partition plots to the list :) The answer was that they store processor_id() on each element using a CONSTANT MONOMIAL in an ExplicitSystem. You can then plot the solution as usual. On 11/25/2013 01:45 PM, subramanya sadasiva wrote: > Hi, is there anyway to see how the mesh has been partitioned in the exodus_ii files?Thanks, Subramanya > >  > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech innovation. > Intel(R) Software Adrenaline delivers strategic insight and gamechanging > conversations that shape the rapidly evolving mobile landscape. Sign up now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers 
From: subramanya sadasiva <potaman@ou...>  20131125 18:45:40

Hi, is there anyway to see how the mesh has been partitioned in the exodus_ii files?Thanks, Subramanya 
From: Lorenzo Zanon <zanon@ai...>  20131125 18:19:41

> Are you sure the Jacobian is correct? Is this a buckling problem, or > something nonsmooth like plasticity or contact? If not, Newton should > converge fairly fast. It should be, running on a 10x2x1 mesh I get convergence and a roughly correct output (wrt FEAP). The problem is just a bar with an applied load, modelled with nonlinear hysotropic elasticity (no plasticity, no contact). > Did you set a near null space (rigid body modes) using > MatSetNearNullSpace and perhaps MatNullSpaceCreateRigidBody? Are you > using a nodal basis? How do you enforce boundary conditions? I'm using Lagrange first order on HEX8 elements. Boundary conditions are set as in the example: std::set<boundary_id_type> boundary_ids; boundary_ids.insert(4); // 3D ... // Create a ZeroFunction to initialize dirichlet_bc ZeroFunction<> zf; DirichletBoundary dirichlet_bc(boundary_ids, variables, &zf); system.get_dof_map().add_dirichlet_boundary(dirichlet_bc); > Do you need the line search? with an NL decay rate that slow one of two things is happening I'd bet  either the Jacobian is incorrect, so your computed dU is not a descent direction(see the increase from steps 24) or the line search is behaving nonoptimally. Testing on the small 10x2x1 problem, without any option it fails: > exampleopt > NL step 0, residual_2 = 3.464102e05 > StVen system solved at nonlinear iteration 0 , final nonlinear residual norm: 3.464102e05 With linesearch and JFNK it works: > exampleopt snes_type ls snes_linesearch_type basic snes_mf_operator > NL step 0, residual_2 = 3.464102e05 > NL step 1, residual_2 = 2.417673e04 > NL step 2, residual_2 = 6.139470e08 > NL step 3, residual_2 = 5.468950e13 > NL step 4, residual_2 = 7.179521e18 > StVen system solved at nonlinear iteration 4 , final nonlinear residual norm: 7.179521e18 Using either linesearch or JFNK it doesn't converge, it looks like I need both. Apparently I can do without LU, but still it's very slow. Thanks Lorenzo On Nov 25, 2013, at 4:01 PM, Kirk, Benjamin (JSCEG311) wrote: > > On Nov 25, 2013, at 6:23 AM, Lorenzo Zanon <zanon@...> > wrote: > >> Hello, >> >> Thanks for the detailed answer! >> >> I've just rerun the executable taking off the snes_mf_operator and LU options, but it doesn't look any better... : >> >> Running ./exampleopt snes_type ls snes_linesearch_type basic ksp_rtol 1e4 >> NL step 0, residual_2 = 1.936492e05 >> NL step 1, residual_2 = 1.938856e05 >> NL step 2, residual_2 = 1.941222e05 >> NL step 3, residual_2 = 1.943592e05 >> NL step 4, residual_2 = 1.945964e05 >> >> Then I stopped it because it didn't look like converging, after one hour or so. >> > > Do you need the line search? with an NL decay rate that slow one of two things is happening I'd bet  either the Jacobian is incorrect, so your computed dU is not a descent direction(see the increase from steps 24) or the line search is behaving nonoptimally. > > I think snes_info (?) will present more verbose information that may be useful to you. > > Ben > 
From: Subramanya Sadasiva <potaman@ou...>  20131125 15:18:17

Hi Benjamin, It is not a strong need. My advisor just wanted to check. Thanks, Subramanya On Nov 25, 2013, at 10:09 AM, Kirk, Benjamin (JSCEG311) <benjamin.kirk@...> wrote: > On Nov 25, 2013, at 9:07 AM, Subramanya Sadasiva <potaman@...> > wrote: > >> one last thing, do I have to build everything for static libraries? including petsc? > > No, that should not be necessary. I can't remember what the issue was trying to build libMesh dynamically  if there is a strong need I can investigate when I'm back to a cygwin machine next week. > > Ben > > 
From: Kirk, Benjamin (JSCEG311) <benjamin.kirk@na...>  20131125 15:09:47

On Nov 25, 2013, at 9:07 AM, Subramanya Sadasiva <potaman@...> wrote: > one last thing, do I have to build everything for static libraries? including petsc? No, that should not be necessary. I can't remember what the issue was trying to build libMesh dynamically  if there is a strong need I can investigate when I'm back to a cygwin machine next week. Ben 
From: Subramanya Sadasiva <potaman@ou...>  20131125 15:07:32

Thanks Benjamin, one last thing, do I have to build everything for static libraries? including petsc? Subramanya On Nov 25, 2013, at 9:57 AM, Kirk, Benjamin (JSCEG311) <benjamin.kirk@...> wrote: > On Nov 25, 2013, at 8:54 AM, Subramanya Sadasiva <potaman@...> > wrote: > >> Does this mean that the mpi stuff doesn’t work with cygwin? > > No, it just means that for the machine I ran that on I didn't have much of a software stack installed. If you've got a decent MPI running under cygwin libMesh should be able to use it. 
From: Kirk, Benjamin (JSCEG311) <benjamin.kirk@na...>  20131125 15:01:42

On Nov 25, 2013, at 6:23 AM, Lorenzo Zanon <zanon@...> wrote: > Hello, > > Thanks for the detailed answer! > > I've just rerun the executable taking off the snes_mf_operator and LU options, but it doesn't look any better... : > > Running ./exampleopt snes_type ls snes_linesearch_type basic ksp_rtol 1e4 > NL step 0, residual_2 = 1.936492e05 > NL step 1, residual_2 = 1.938856e05 > NL step 2, residual_2 = 1.941222e05 > NL step 3, residual_2 = 1.943592e05 > NL step 4, residual_2 = 1.945964e05 > > Then I stopped it because it didn't look like converging, after one hour or so. > Do you need the line search? with an NL decay rate that slow one of two things is happening I'd bet  either the Jacobian is incorrect, so your computed dU is not a descent direction(see the increase from steps 24) or the line search is behaving nonoptimally. I think snes_info (?) will present more verbose information that may be useful to you. Ben 
From: Kirk, Benjamin (JSCEG311) <benjamin.kirk@na...>  20131125 14:57:09

On Nov 25, 2013, at 8:54 AM, Subramanya Sadasiva <potaman@...> wrote: > Does this mean that the mpi stuff doesn’t work with cygwin? No, it just means that for the machine I ran that on I didn't have much of a software stack installed. If you've got a decent MPI running under cygwin libMesh should be able to use it. 
From: Subramanya Sadasiva <potaman@ou...>  20131125 14:55:02

Hi Kirk, Does this mean that the mpi stuff doesn’t work with cygwin? Thanks, Subramanya On Nov 25, 2013, at 9:52 AM, Kirk, Benjamin (JSCEG311) <benjamin.kirk@...> wrote: > It's been a while for me too, but I occasionally test on Cygwin when I'm trapped in a room with windows computers. > > Try something like this: > > $ ./configure prefix=`pwd`/inst disablempi disableshared enablestatic METHODS=opt > > (from https://github.com/libMesh/libmesh/issues/43) > > and please report the results  as Roy says, this should always work but because it is rarely tested your results may vary! > > Ben > > > On Nov 24, 2013, at 11:26 PM, subramanya sadasiva <potaman@...> wrote: > >> I kind of agree with Derek, but we have collaborators who are very windows people >> >>  Original Message  >> >> From: "Roy Stogner" <roystgnr@...> >> Sent: November 24, 2013 10:38 PM >> To: "subramanya sadasiva" <potaman@...> >> Cc: libmeshusers@... >> Subject: Re: [Libmeshusers] Installing through Cygwin. >> >> >> On Sat, 23 Nov 2013, subramanya sadasiva wrote: >> >>> are there any specific instructions on how to install libmesh on cygwin? >> >> Just "email libmeshusers if you have problems". In theory it should >> work; in practice I think I'm the only one who doublechecks cygwin >> compatibility and I don't get to it every year even. >>  >> Roy >> >>  >> Shape the Mobile Experience: Free Subscription >> Software experts and developers: Be at the forefront of tech innovation. >> Intel(R) Software Adrenaline delivers strategic insight and gamechanging >> conversations that shape the rapidly evolving mobile landscape. Sign up now. >> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >> _______________________________________________ >> Libmeshusers mailing list >> Libmeshusers@... >> https://lists.sourceforge.net/lists/listinfo/libmeshusers > 
From: Kirk, Benjamin (JSCEG311) <benjamin.kirk@na...>  20131125 14:52:29

It's been a while for me too, but I occasionally test on Cygwin when I'm trapped in a room with windows computers. Try something like this: $ ./configure prefix=`pwd`/inst disablempi disableshared enablestatic METHODS=opt (from https://github.com/libMesh/libmesh/issues/43) and please report the results  as Roy says, this should always work but because it is rarely tested your results may vary! Ben On Nov 24, 2013, at 11:26 PM, subramanya sadasiva <potaman@...> wrote: > I kind of agree with Derek, but we have collaborators who are very windows people > >  Original Message  > > From: "Roy Stogner" <roystgnr@...> > Sent: November 24, 2013 10:38 PM > To: "subramanya sadasiva" <potaman@...> > Cc: libmeshusers@... > Subject: Re: [Libmeshusers] Installing through Cygwin. > > > On Sat, 23 Nov 2013, subramanya sadasiva wrote: > >> are there any specific instructions on how to install libmesh on cygwin? > > Just "email libmeshusers if you have problems". In theory it should > work; in practice I think I'm the only one who doublechecks cygwin > compatibility and I don't get to it every year even. >  > Roy > >  > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech innovation. > Intel(R) Software Adrenaline delivers strategic insight and gamechanging > conversations that shape the rapidly evolving mobile landscape. Sign up now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers 