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}
(84) 
_{Oct}
(82) 
_{Nov}
(69) 
_{Dec}
(45) 
2016 
_{Jan}
(92) 
_{Feb}
(91) 
_{Mar}
(148) 
_{Apr}
(43) 
_{May}
(58) 
_{Jun}
(117) 
_{Jul}
(92) 
_{Aug}
(140) 
_{Sep}
(49) 
_{Oct}
(33) 
_{Nov}
(85) 
_{Dec}
(40) 
2017 
_{Jan}
(41) 
_{Feb}
(28) 
_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 






1
(4) 
2
(1) 
3

4
(2) 
5
(1) 
6
(1) 
7

8
(2) 
9

10

11

12

13
(6) 
14
(8) 
15
(1) 
16
(1) 
17
(2) 
18
(2) 
19
(2) 
20
(5) 
21
(15) 
22

23
(1) 
24

25
(5) 
26
(7) 
27
(7) 
28
(3) 
29
(18) 

From: Roy Stogner <roystgnr@ic...>  20080227 14:49:51

On Wed, 27 Feb 2008, John Peterson wrote: > Shengli Xu writes: > > Hello, libmesh users, > > > > The node number is not the same with that in the input unv file in > > libmesh0.6.2 > > > > ... > > > > Is this a bug? If not, How can I let the node number in libmesh0.6.2 to be > > the same as the input file? > > > > In general, we have never guaranteed that would be the case. If it > happened to be in one version of libmesh I guess that was just lucky. > LibMesh's mesh data structure needs to do various operations which > sometimes require renumbering nodes and elements. There's no way > we could support 510 different input file formats while maintaining > the numbering in all of them. We definitely don't support fixed node numbers through many operations. Refinement, repartitioning, etc. all need to change node and element numbers, because we keep those numbers in contiguous ranges on each processor. However, we probably ought to be able to preserve the node numbers from a file format at the initial Mesh::read, even if we have to do a mediocre initial partitioning (i.e. the contiguous ranges of element numbers become the partition) to do so. That would allow people who have tacked on nodal/element data vectors to associate that data with nodes/elements properly rather than just with their numbers before the mesh is next altered. It's up to Ben, though, I think; I don't have enough experience digging around in our I/O code.  Roy 
From: John Peterson <peterson@cf...>  20080227 14:40:45

Shengli Xu writes: > Hello, libmesh users, > > The node number is not the same with that in the input unv file in > libmesh0.6.2 > > ... > > Is this a bug? If not, How can I let the node number in libmesh0.6.2 to be > the same as the input file? > In general, we have never guaranteed that would be the case. If it happened to be in one version of libmesh I guess that was just lucky. LibMesh's mesh data structure needs to do various operations which sometimes require renumbering nodes and elements. There's no way we could support 510 different input file formats while maintaining the numbering in all of them. J 
From: Shengli Xu <shengli.xu.xu@gm...>  20080227 10:35:26

Hello, libmesh users, The node number is not the same with that in the input unv file in libmesh0.6.2 The input unv file is: 8 node, 1 Q8 element 1 2411 0 0 0 0 0.00000000000000000000 0.00000000000000000000 0.00000000000000000000 1 0 0 0 1.00000000000000000000 0.00000000000000000000 0.00000000000000000000 2 0 0 0 0.50000000000000000000 0.00000000000000000000 0.00000000000000000000 3 0 0 0 1.00000000000000000000 1.00000000000000000000 0.00000000000000000000 4 0 0 0 1.00000000000000000000 0.50000000000000000000 0.00000000000000000000 5 0 0 0 0.00000000000000000000 1.00000000000000000000 0.00000000000000000000 6 0 0 0 0.50000000000000000000 1.00000000000000000000 0.00000000000000000000 7 0 0 0 0.00000000000000000000 0.50000000000000000000 0.00000000000000000000 1 1 2412 0 45 2 1 7 8 0 2 1 4 3 6 5 7 1 The node number in libmesh0.6.2 is: NodeNum is 0, x= 0, y= 0 NodeNum is 1, x= 0, y= 1 NodeNum is 2, x= 1, y= 1 NodeNum is 3, x= 1, y= 0 NodeNum is 4, x= 0, y= 0.5 NodeNum is 5, x= 0.5, y= 1 NodeNum is 6, x= 1, y= 0.5 NodeNum is 7, x= 0.5, y= 0 But in libmesh0.5.0, the node number is correct: NodeNum is 0, x= 0, y= 0 NodeNum is 1, x= 1, y= 0 NodeNum is 2, x= 0.5, y= 0 NodeNum is 3, x= 1, y= 1 NodeNum is 4, x= 1, y= 0.5 NodeNum is 5, x= 0, y= 1 NodeNum is 6, x= 0.5, y= 1 NodeNum is 7, x= 0, y= 0.5 Is this a bug? If not, How can I let the node number in libmesh0.6.2 to be the same as the input file?  Best regards, Yours sincerely ShengliXu Department of Engineering Mechanics State Key Laboratory of Structural Analysis for Industrial Equipment Dalian University of Technology Dalian, 116023, P. R. China Email: shengli.xu.xu@... ========================== 
From: Roy Stogner <roystgnr@ic...>  20080226 18:13:33

On Tue, 26 Feb 2008, Zbigniew Romanowski wrote: > I am particularly interested in positive definite operators > \nabla^2 + U(x) > corresponding to reals eigenvalues. Do the bug appear also for this type > of equation? Not to my knowledge. I haven't been able to replicate any bug without enablecomplex turned on. But the fact that we've seen any bug at all suggests that some of the eigensolver code isn't as welltested as it should be. > As far as I know, for efficient adaptive procedure the estimation of the > eigenvalue error is crucial. Could you please provide the documentation > about the eigenvalue error estimators implemented in libMesh for > ordinary and generalized eigenvalue problem? This would be very helpful. There are none that apply to general problems, I'm afraid. One reason is that if you want a rigorous upper bound on your error, you generally need cell residuals, and libMesh only has access to the weak form of the users' PDEs, not the strong form. A second reason is that most of the primary developers have been using adaptivity based on error indicators that are simplified for speed and ease of implementation (e.g. using the jump indicators even on problems for which they are not proportional to a rigorous bound). This is usually sufficient for directing adaptive refinement/coarsening, but it's not enough to prove error bounds on your results. In general (and especially for nonlinear PDEs), proven error bounds depend enough on the particular boundary value problem you're trying to solve that we can't provide a "one size fits all" solution. It looks like you're operating on a simple enough problem (second order, linear, unit coefficient on the linear operator) that you might be able to start with our Kelly jump indicator, add a handcoded residual corresponding to the U(x) term, and get a real upper bound. But that's just off the top of my head. Even if it works you might get a uselessly loose upper bound. There should be lots of cancellation if it's just the eigenvalue error you're looking for, not the eigenfunction error, and I don't know enough about eigenproblem error analysis to know how that should be handled.  Roy 
From: John Peterson <peterson@cf...>  20080226 17:56:57

Zbigniew Romanowski writes: > Hi Roy, > > Thank you for your fast response. > I am particularly interested in positive definite operators > \nabla^2 + U(x) > corresponding to reals eigenvalues. Do the bug appear also for this type > of equation? > > As far as I know, for efficient adaptive procedure the estimation of the > eigenvalue error is crucial. Could you please provide the documentation > about the eigenvalue error estimators implemented in libMesh for > ordinary and generalized eigenvalue problem? This would be very helpful. The library doesn't provide eigenvalue error estimators per se, only explicit a posteriori type indicators for FE solutions. If I understand correctly, error estimation for eigenproblems is a topic of current research interest and we would welcome any contributions to the library in this area. J > > Best regards, > Zbigniew > >  > PATTON & FENNESZ. Kolejny projekt Mikea Pattona >  wokalisty Faith No More 29.02 20:00 Proxima /Warszawa > bilety: Ticketonline, Ticketpro, Shortcut, Eventim, Proxima > http://www.goahead.pl http://klik.wp.pl/?adr=http%3A%2F%2Fcorto.www.wp.pl%2Fas%2Fpatton.html&sid=238 > > > >  > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers 
From: Zbigniew Romanowski <romz@wp...>  20080226 17:52:05

Hi Roy, Thank you for your fast response. I am particularly interested in positive definite operators \nabla^2 + U(x) corresponding to reals eigenvalues. Do the bug appear also for this type of equation? As far as I know, for efficient adaptive procedure the estimation of the eigenvalue error is crucial. Could you please provide the documentation about the eigenvalue error estimators implemented in libMesh for ordinary and generalized eigenvalue problem? This would be very helpful. Best regards, Zbigniew  PATTON & FENNESZ. Kolejny projekt Mikea Pattona  wokalisty Faith No More 29.02 20:00 Proxima /Warszawa bilety: Ticketonline, Ticketpro, Shortcut, Eventim, Proxima http://www.goahead.pl http://klik.wp.pl/?adr=http%3A%2F%2Fcorto.www.wp.pl%2Fas%2Fpatton.html&sid=238 
From: Roy Stogner <roystgnr@ic...>  20080226 15:45:04

On Tue, 26 Feb 2008, Zbigniew Romanowski wrote: > Could you please answer following question: > > Is libMesh ready to solve the eigenvalue problem in R^3 space > > (\nabla^2 + U(x)) \Psi = \lambda \Psi(x) > > for defined U(x): R^3 > R using adaptive algorithm with hanging nodes? The answer should be "yes". But, just this morning someone found an apparent bug with the developmental version of our example eigenvalue solver program when using complexvalued solutions. I think only one of our active developers is doing frequent eigenvalue problems at the moment, so it's possible there may be other cornercase bugs that you might have to help root out.  Roy 
From: Roy Stogner <roystgnr@ic...>  20080226 15:27:00

On Tue, 26 Feb 2008, Christophe Trophime wrote: > I am trying to build a rpm for libmesh from svn on FC7. > I have compiled libmesh with the following option with openmpi > (openmpi1.18.fc7) : A lot of these options are redundant; they're either on by default or turned on by enableeverything. Some options you may not want to use; enablecomplex has a lot of overhead on Realvalued problems, and enablereferencecounting is probably unnecessary when you're not debugging. enableperflog (turned on by enableeverything) has noticeable overhead too. Anyway, when you do get things the way you want, send us the .spec file? We haven't built RPMs of libMesh in too long. > The examples ex17 ends up with a seg fault : > > *************************************************************** > * Running Example ./ex17opt n 5 > *************************************************************** Would you try running with METHOD=dbg? We might catch some internal error condition before the segfault. Anyway, I can't replicate this segfault with SLEPc 2.3.1, PETSc 2.3.1p16, and MPICH 1.2.7, but OpenMPI is easy enough to install so I'll try again with that later. There's definitely some bug with ex17 and enablecomplex; for me it dies on a zero pivot when PETSc starts building a preconditioner.  Roy 
From: Zbigniew Romanowski <romz@wp...>  20080226 15:16:53

Hi All, Could you please answer following question: Is libMesh ready to solve the eigenvalue problem in R^3 space (\nabla^2 + U(x)) \Psi = \lambda \Psi(x) for defined U(x): R^3 > R using adaptive algorithm with hanging nodes? Thank you in advance, Zbigniew  Seksowne tancerki i zakochani młodzi mężczyźni, oraz gangsterzy trzymający twardą ręką show biznes. Zobacz to na żywo: http://klik.wp.pl/?adr=http%3A%2F%2Fcorto.www.wp.pl%2Fas%2FLeweinteresy.html&sid=236 
From: Christophe Trophime <christophe.trophime@gr...>  20080226 10:29:39

I am trying to build a rpm for libmesh from svn on FC7. I have compiled libmesh with the following option with openmpi (openmpi1.18.fc7) : ./configure prefix=/usr/local/%{name}openmpi%{version} \ enableeverything \ enableamr \ enableperiodic \ enablepfem \ enableifem \ enablecomplex \ enablesecond \ enablexdr \ enablereferencecounting \ enableoptional \ enablempi \ enablepetsc \ enableslepc \ enabletbb \ enablelaspack \ enablesfc \ enablegzstreams \ enabletecplot \ enablemetis \ enableparmetis \ enabletetgen \ enabletriangle \ enablegmv \ enablevtk \ enablenetcdf \ enableexodus \ enablelibHilbert \ withvtklib=%{_libdir} \ CC=mpicc CXX=mpic++ The examples ex17 ends up with a seg fault : *************************************************************** * Running Example ./ex17opt n 5 *************************************************************** Running ./ex17opt n 5 Mesh Information: mesh_dimension()=2 spatial_dimension()=3 n_nodes()=441 n_local_nodes()=441 n_elem()=400 n_local_elem()=400 n_active_elem()=400 n_subdomains()=1 n_processors()=1 processor_id()=0 EquationSystems n_systems()=1 System "Eigensystem" Type "Eigen" Variables="p" Finite Element Types="LAGRANGE", "JACOBI_20_00" Infinite Element Mapping="CARTESIAN" Approximation Orders="FIRST", "THIRD" n_dofs()=441 n_local_dofs()=441 n_constrained_dofs()=0 n_vectors()=0 Number of converged eigenpairs: 5 [0]PETSC ERROR:  [0]PETSC ERROR: Caught signal number 11 SEGV: Segmentation Violation, probably memory access out of range [0]PETSC ERROR: Try option start_in_debugger or on_error_attach_debugger [0]PETSC ERROR: or see http://www.mcs.anl.gov/petsc/petscas/documentation/troubleshooting.html#Signal[0]PETSC ERROR: or try http://valgrind.org on linux or man libgmalloc on Apple to find memory corruption errors [0]PETSC ERROR: configure using withdebugging=yes, recompile, link, and run [0]PETSC ERROR: to get more information on the crash. [0]PETSC ERROR:  Error Message  [0]PETSC ERROR: Signal received! [0]PETSC ERROR:  [0]PETSC ERROR: Petsc Release Version 2.3.3, Patch 8, Fri Nov 16 17:03:40 CST 2007 HG revision: 414581156e67e55c761739b0deb119f7590d0f4b [0]PETSC ERROR: See docs/changes/index.html for recent updates. [0]PETSC ERROR: See docs/faq.html for hints about trouble shooting. [0]PETSC ERROR: See docs/index.html for manual pages. [0]PETSC ERROR:  [0]PETSC ERROR: ./ex17opt on a linuxgnu named calcul8.lcmi.local by trophime Tue Feb 26 09:43:19 2008 [0]PETSC ERROR: Libraries linked from /usr/local/petsc/lib/linuxgnucxxoptopenmpi [0]PETSC ERROR: Configure run at Fri Feb 15 14:16:50 2008 [0]PETSC ERROR: Configure options CFLAGS=O2 g pipe Wall Wp,D_FORTIFY_SOURCE=2 fexceptions fstackprotector param=sspbuffersize=4 m64 mtune=generic CXXFLAGS=O2 g pipe Wall Wp,D_FORTIFY_SOURCE=2 fexceptions fstackprotector param=sspbuffersize=4 m64 mtune=generic withdebugging=no PETSC_DIR=/home/trophime/rpmbuild/BUILD/petsc2.3.3p8 PETSC_ARCH=linuxgnucxxoptopenmpi prefix=/usr/local/petsc withshared withx=1 downloadhypre=1 downloadblopex=1 withclanguage=C++ withcsupport [0]PETSC ERROR:  [0]PETSC ERROR: User provided function() line 0 in unknown directory unknown file [calcul8.lcmi.local:11513] [0,0,0] ORTE_ERROR_LOG: Not found in file base/pls_base_proxy.c at line 189   Time: Tue Feb 26 09:43:19 2008   OS: Linux   HostName: calcul8.lcmi.local   OS Release: 2.6.23.1464.fc7   OS Version: #1 SMP Sun Jan 20 22:20:19 EST 2008   Machine: x86_64   Username: trophime   Configuration: ./configure run on Tue Feb 26 09:33:39 CET 2008     libMesh Performance: Alive time=0.211647, Active time=0.173877    Event nCalls Total Avg Percent of   Time Time Active Time        DofMap   add_neighbors_to_send_list() 1 0.0001 0.000145 0.08   compute_sparsity() 1 0.0022 0.002247 1.29   create_dof_constraints() 1 0.0001 0.000105 0.06   distribute_dofs() 1 0.0016 0.001587 0.91   dof_indices() 1200 0.0022 0.000002 1.25   reinit() 1 0.0011 0.001084 0.62   sort_send_list() 1 0.0000 0.000014 0.01     FE   compute_affine_map() 400 0.0010 0.000002 0.57   compute_shape_functions() 400 0.0008 0.000002 0.45   init_shape_functions() 1 0.0001 0.000091 0.05     Mesh   find_neighbors() 1 0.0015 0.001524 0.88   renumber_nodes_and_elem() 1 0.0000 0.000029 0.02     MeshTools::Generation   build_cube() 1 0.0004 0.000410 0.24     SlepcEigenSolver   solve_generalized() 1 0.1568 0.156846 90.21     System   assemble() 1 0.0058 0.005832 3.35    Totals: 2012 0.1739 100.00   make[2]: *** [run] Error 59 
From: Benjamin Kirk <benjamin.kirk@na...>  20080225 21:36:37

> I am curious as to what kind of multiphysics problems you have solved > with Libmesh before and what kind of approach you took for those. I > gather you used a single mesh for both the physics but where you able > to preserve the accuracy of the coupled solution in space and time ? > And did you use Operatorsplitting with iterations over the coupled > physics ? Actually most recently I have been working the conjugate heat transfer problem. The "external" application is hypersonic flight and the "internal" application is solidbody conduction. This uses two meshes, one for the fluid flow and one for the heat transfer. An operatorsplit approach is natural in this problem because of the disparate time scales. The external flow characteristic times are ~microseconds while the heat transfer problem is ~seconds. The approach couples the problem at the boundary. The temperature is interpolated from the heat transfer part to provide an isothermal boundary condition for the flow. The heat transfer is then interpolated from the fluid part and transformed into a heat transfer coefficient boundary condition for the heat transfer problem. It works well because the heat transfer coefficient is approximately constant for a small range in wall temperature, so the time coupling here is especially loose. Ben 
From: Roy Stogner <roystgnr@ic...>  20080225 19:19:06

On Mon, 25 Feb 2008, Yujie wrote: > Thank you for your reply. In fact, the basic problem is how to know the > relationship between the solution variables (one or several) and > the nonsolution variables(one or > several). If one uses two Systems for them, one for solution > variables, the other for nonsolution variables. Only one mesh is for > them. Assuming firstorder Lagrange shape function is used, how to > establish the relationship using the nodes on the mesh > or other information? For example, there are three solution variables (u, v, > p) on node 1 of the mesh in System 1, there > are two nonsolution variables (x, y) on node 1 of the mesh in System 2, > how to know they are relevant to node 1? That's what the DofMap class is for; give an Elem object (and possibly a variable number) to DofMap::dof_indices() and it will fill a vector with the global DoF index numbers for that variable(s) on that element. Alternatively, if you only want to use Lagrange shape functions, you can use the DofObject class methods to directly find the indices on a Node.  Roy 
From: Yujie <recrusader@gm...>  20080225 19:12:21

Dear Roy: Thank you for your reply. In fact, the basic problem is how to know the relationship between the solution variables (one or several) and the nonsolution variables(one or several). If one uses two Systems for them, one for solution variables, the other for nonsolution variables. Only one mesh is for them. Assuming firstorder Lagrange shape function is used, how to establish the relationship using the nodes on the mesh or other information? For example, there are three solution variables (u, v, p) on node 1 of the mesh in System 1, there are two nonsolution variables (x, y) on node 1 of the mesh in System 2, how to know they are relevant to node 1? thanks a lot. Regards, Yujie On 2/25/08, Roy Stogner <roystgnr@...> wrote: > > > On Mon, 25 Feb 2008, Yujie wrote: > > > Could you give me some hints to the email I have sent last week? > > > Yeah; sorry I let it get buried but it's been a busy week. > > > > In addition, even if you use another System, how to guarantee the > > Dof in one System is the same with that of the other, especially > > numbering? > > > If you use the same finite element spaces you should get the same > numbering, but don't count on that. Use the DoFMap in each system to > get the indexing of each variable, and then they don't have to be the > same. > > > > If there are several solution variables in the System, the > > nonsolution variable is only relevant to the nodes on the mesh, what > > is there are different Dofs between them, how to deal with it? > > > See ex13; there are multiple variables there, and to get their values > you can use the DofMap to get the local indices, use an appropriate FE > objct to get the shape functions, then do the sums at each quadrature > point. If the variables are in separate systems, all that changes is > that you have to use the DofMap in each system to get its own > variables. > > > > You agree that the best method is to add another system to the > > EquationSystems. You also consider that it is ok to use add_vector() > > to add a vector for the nonsolution variable. My problem is how to > > distribute the vector you add corresponding to DoF distribution on > > processors of the cluster when you add the vector? > > > Assuming both Systems are in the same EquationSystems object, they'll > be using the same Mesh with the same partitioning. The library will > handle parallel redistribution for you. > > > > Any functions in libmesh help keep this vector, such as initializing > > the distribution of this vector, updating this vector along with the > > change of Dof after refining mesh, and so on? thanks a lot. > > > EquationSystems::init() should handle the original distribution of the > vector, and EquationSystems::reinit() should do everything you need > after a mesh refinement. >  > > Roy > 
From: Roy Stogner <roystgnr@ic...>  20080225 18:44:37

On Mon, 25 Feb 2008, Yujie wrote: > Could you give me some hints to the email I have sent last week? Yeah; sorry I let it get buried but it's been a busy week. > In addition, even if you use another System, how to guarantee the > Dof in one System is the same with that of the other, especially > numbering? If you use the same finite element spaces you should get the same numbering, but don't count on that. Use the DoFMap in each system to get the indexing of each variable, and then they don't have to be the same. > If there are several solution variables in the System, the > nonsolution variable is only relevant to the nodes on the mesh, what > is there are different Dofs between them, how to deal with it? See ex13; there are multiple variables there, and to get their values you can use the DofMap to get the local indices, use an appropriate FE objct to get the shape functions, then do the sums at each quadrature point. If the variables are in separate systems, all that changes is that you have to use the DofMap in each system to get its own variables. > You agree that the best method is to add another system to the > EquationSystems. You also consider that it is ok to use add_vector() > to add a vector for the nonsolution variable. My problem is how to > distribute the vector you add corresponding to DoF distribution on > processors of the cluster when you add the vector? Assuming both Systems are in the same EquationSystems object, they'll be using the same Mesh with the same partitioning. The library will handle parallel redistribution for you. > Any functions in libmesh help keep this vector, such as initializing > the distribution of this vector, updating this vector along with the > change of Dof after refining mesh, and so on? thanks a lot. EquationSystems::init() should handle the original distribution of the vector, and EquationSystems::reinit() should do everything you need after a mesh refinement.  Roy 
From: Essau Magos <naumanen1994@STARLITE.DK>  20080225 15:18:02

She will start screaming in pleasure from now on! 
From: Yujie <recrusader@gm...>  20080223 01:46:29

Dear Roy: I check the mail list and find the following question and your answer, which is in "Re: [Libmeshusers] variables and vectors in equation systems?" > The easiest way that I could think of setting up independent > variables is to add another System to the EquationSystems, > deactivate this System so that it is not solved, and add the > independent variables to this System. That's the best general method I can come up with too. A nonsolution function defined on an unstructured finite element space will need the same sort of DoF mapping structure that your solution variables need, and currently the only way to set that up is to add your function as a solution variable somewhere or to reuse the mapping of a real solution variable. If you want to reuse the mapping of most or all the solution variables in a system (as time solvers do, for example) then the most efficient way to get that is add_vector(). You agree that the best method is to add another system to the EquationSystems. You also consider that it is ok to use add_vector() to add a vector for the nonsolution variable. My problem is how to distribute the vector you add corresponding to DoF distribution on processors of the cluster when you add the vector? Any functions in libmesh help keep this vector, such as initializing the distribution of this vector, updating this vector along with the change of Dof after refining mesh, and so on? thanks a lot. Regards, Yujie 
From: John Peterson <peterson@cf...>  20080221 20:57:52

pcorreia@... writes: > >>> I want to solve a pde equation involving a parameter to be incremented > >>> sucessively. After obtaining a solution I want to use it as a guess > >>> for > >>> the system to be solved next. How can I implement this? > > > >> I'm not an expert on Libmesh, but I recall that PETSC allows one to > >> set the iinitial guess. If PETSc can be accessed through the libmesh > >> interface then it should be possible quite easily. > > > > Indeed it is  this is in fact the default behavior in libMesh. Whatever > > is in the System.solution vector is handed off to the linear solver as the > > initial guess. You should be able to verify this by calling > > > > equation_systems.solve(); > > equation_systems.solve(); > > > > And seeing that the second solve converges in 0 iterations. > > > In fact I obtain: > Is this being run in parallel by any chance? I wonder if you need a system.update() in between the solves so that during the second assembly you get the most recent values from current_local_solution? Any chance you could post a short version of your code that shows the problem? J 
From: Benjamin Kirk <benjamin.kirk@na...>  20080221 20:23:10

>>> I'm not an expert on Libmesh, but I recall that PETSC allows one to >>> set the iinitial guess. If PETSc can be accessed through the libmesh >>> interface then it should be possible quite easily. >> >> Indeed it is  this is in fact the default behavior in libMesh. Whatever >> is in the System.solution vector is handed off to the linear solver as the >> initial guess. You should be able to verify this by calling >> >> equation_systems.solve(); >> equation_systems.solve(); >> >> And seeing that the second solve converges in 0 iterations. > ... > > It seems there is no change... > I'm not sure what is going on in your application... If I take ex4 and add a second solve as mentioned above and run $ ./ex4dbg d 2 n 20 ksp_converged_reason I get Linear solve converged due to CONVERGED_RTOL iterations 78 Linear solve converged due to CONVERGED_RTOL iterations 0 
From: <pcorreia@ue...>  20080221 20:01:53

>>> I want to solve a pde equation involving a parameter to be incremented >>> sucessively. After obtaining a solution I want to use it as a guess >>> for >>> the system to be solved next. How can I implement this? > >> I'm not an expert on Libmesh, but I recall that PETSC allows one to >> set the iinitial guess. If PETSc can be accessed through the libmesh >> interface then it should be possible quite easily. > > Indeed it is  this is in fact the default behavior in libMesh. Whatever > is in the System.solution vector is handed off to the linear solver as the > initial guess. You should be able to verify this by calling > > equation_systems.solve(); > equation_systems.solve(); > > And seeing that the second solve converges in 0 iterations. In fact I obtain:   Matrix Assembly Performance: Alive time=0.587006, Active time=0.543755   Event nCalls Total Avg Percent of   Time Time Active Time      BCs 1536 0.0074 0.000005 1.36   Ke 512 0.0040 0.000008 0.74   elem init 512 0.0096 0.000019 1.76   side integration 1536 0.5228 0.000340 96.14    Totals: 4096 0.5438 100.00   Transport_2 linear solver converged at step: 14, final residual: 9.89093e06   Matrix Assembly Performance: Alive time=0.844928, Active time=0.803292   Event nCalls Total Avg Percent of   Time Time Active Time      BCs 1536 0.0082 0.000005 1.02   Ke 512 0.0042 0.000008 0.52   elem init 512 0.0097 0.000019 1.21   side integration 1536 0.7812 0.000509 97.25    Totals: 4096 0.8033 100.00   Transport_2A linear solver converged at step: 14, final residual: 9.89093e06 It seems there is no change... > > Ben > 
From: Roy Stogner <roystgnr@ic...>  20080221 19:27:40

On Thu, 21 Feb 2008, Roy Stogner wrote: >> initial guess. You should be able to verify this by calling >> >> equation_systems.solve(); >> equation_systems.solve(); >> >> And seeing that the second solve converges in 0 iterations. > > Wait, doesn't that depend on your tolerance settings? If you're using > a relative residual reduction, the second solve will start from a > smaller initial residual than the first solve, and will have to do > work to make that residual even smaller. Wait, actually, it depends. That applies to nonlinear solvers where the assembled residual is a function of the initial guess for the solution, but for linear problems where the right hand side of the equation is a solutionindependent forcing function you're right.  Roy 
From: Roy Stogner <roystgnr@ic...>  20080221 19:25:47

On Thu, 21 Feb 2008, Benjamin Kirk wrote: >>> I want to solve a pde equation involving a parameter to be incremented >>> sucessively. After obtaining a solution I want to use it as a guess for >>> the system to be solved next. How can I implement this? > >> I'm not an expert on Libmesh, but I recall that PETSC allows one to >> set the iinitial guess. If PETSc can be accessed through the libmesh >> interface then it should be possible quite easily. > > Indeed it is  this is in fact the default behavior in libMesh. Whatever > is in the System.solution vector is handed off to the linear solver as the > initial guess. You should be able to verify this by calling > > equation_systems.solve(); > equation_systems.solve(); > > And seeing that the second solve converges in 0 iterations. Wait, doesn't that depend on your tolerance settings? If you're using a relative residual reduction, the second solve will start from a smaller initial residual than the first solve, and will have to do work to make that residual even smaller.  Roy 
From: Benjamin Kirk <benjamin.kirk@na...>  20080221 19:18:33

>> I want to solve a pde equation involving a parameter to be incremented >> sucessively. After obtaining a solution I want to use it as a guess for >> the system to be solved next. How can I implement this? > I'm not an expert on Libmesh, but I recall that PETSC allows one to > set the iinitial guess. If PETSc can be accessed through the libmesh > interface then it should be possible quite easily. Indeed it is  this is in fact the default behavior in libMesh. Whatever is in the System.solution vector is handed off to the linear solver as the initial guess. You should be able to verify this by calling equation_systems.solve(); equation_systems.solve(); And seeing that the second solve converges in 0 iterations. Ben 
From: Roy Stogner <roystgnr@ic...>  20080221 19:16:16

On Thu, 21 Feb 2008, Nachiket Gokhale wrote: > I'm not an expert on Libmesh, but I recall that PETSC allows one to > set the iinitial guess. If PETSc can be accessed through the libmesh > interface then it should be possible quite easily. The behavior in libMesh should (in this case) be practically automatic: the current System.solution value gets used as the initial guess in the next solve. I've only verified this behavior for the NewtonSolver I wrote, but I seem to recall us fixing one of the other solvers to make sure it worked that way too. In other words, after solving your system with parameter 1, you ought to be able to just solve it again with parameter 2 and it'll begin iterating from the parameter 1 solution. If one of the solver classes doesn't have that behavior let us know; I'd consider it a bug.  Roy 
From: Nachiket Gokhale <gokhalen@gm...>  20080221 19:00:59

I'm not an expert on Libmesh, but I recall that PETSC allows one to set the iinitial guess. If PETSc can be accessed through the libmesh interface then it should be possible quite easily. I'll wait for the experts to give an authoritative answer. :) Nachiket On Thu, Feb 21, 2008 at 1:52 PM, <pcorreia@...> wrote: > Hi, > I want to solve a pde equation involving a parameter to be incremented > sucessively. After obtaining a solution I want to use it as a guess for > the system to be solved next. How can I implement this? > Thanks > Paulo > > > > > >  > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers > 
From: <pcorreia@ue...>  20080221 18:52:51

Hi, I want to solve a pde equation involving a parameter to be incremented sucessively. After obtaining a solution I want to use it as a guess for the system to be solved next. How can I implement this? Thanks Paulo 