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}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 





1

2

3

4

5
(2) 
6
(1) 
7
(9) 
8
(2) 
9

10

11

12
(15) 
13
(18) 
14
(11) 
15
(5) 
16
(10) 
17

18

19
(3) 
20
(9) 
21
(7) 
22
(5) 
23

24

25

26

27
(3) 
28
(4) 
29
(4) 
30
(1) 
31

From: Brent Kraczek <bkraczek@ic...>  20090130 17:00:07

Thanks everyone. Sorry about the silly error. I did run into one more problem before I was able to get it working. The mesh generator I was using uses a different handedness of tetrahedra than libmesh was expecting. The result was that I was getting an error message saying that I had a negative Jacobian. It took me a little while to figureout what the cause was. So, when documentation is written about the format, it might be nice to include that point. Thanks again, Brent Roy Stogner wrote: > > > On Thu, 29 Jan 2009, Brent Kraczek wrote: > >> ERROR: Finite element LAGRANGE on geometric element TET >> only supports FEInterface::max_order = 1, not fe_type.order = 2 > > John seems to have figured out the problem here... although the error > message should be telling you TET4, not TET, which may be a regression > from some of my recent code; I'll go doublecheck that now. > >> WARNING: Finite element LAGRANGE on geometric element TET >> could not be p refined past FEInterface::max_order = 1 >> ERROR: unsigned char too small to hold Elem::_p_level! >> Recompile with Elem:_p_level set to something bigger! >> What I have found through digging is that when it goes to >> reinitialize the mesh (DofMap::reinit) it finds that fe_type.order == >> 2; elem>p_level()==255 > > This is probably a weird sideeffect of the same problem (the p > refinement code tries to bump down the p level to what the element can > support, but because there's been no p refinement the level just goes > from 0 to 1...); I'll add a check to fix that. But it could be an > I/O issue too; let us know if it persists. >  > Roy 
From: Roy Stogner <roystgnr@ic...>  20090129 23:22:04

On Thu, 29 Jan 2009, Brent Kraczek wrote: > ERROR: Finite element LAGRANGE on geometric element TET > only supports FEInterface::max_order = 1, not fe_type.order = 2 John seems to have figured out the problem here... although the error message should be telling you TET4, not TET, which may be a regression from some of my recent code; I'll go doublecheck that now. > WARNING: Finite element LAGRANGE on geometric element TET > could not be p refined past FEInterface::max_order = 1 > ERROR: unsigned char too small to hold Elem::_p_level! > Recompile with Elem:_p_level set to something bigger! > What I have found through digging is that when it goes to reinitialize the > mesh (DofMap::reinit) it finds that fe_type.order == 2; elem>p_level()==255 This is probably a weird sideeffect of the same problem (the p refinement code tries to bump down the p level to what the element can support, but because there's been no p refinement the level just goes from 0 to 1...); I'll add a check to fix that. But it could be an I/O issue too; let us know if it persists.  Roy 
From: John Peterson <jwpeterson@gm...>  20090129 23:16:09

On Thu, Jan 29, 2009 at 5:15 PM, John Peterson <jwpeterson@...> wrote: > On Thu, Jan 29, 2009 at 4:54 PM, Brent Kraczek <bkraczek@...> wrote: >> However, when attempting to use this mesh I get the following error >> messages: >> >> >> >> \begin{verbatim} >> ERROR: Finite element LAGRANGE on geometric element TET >> only supports FEInterface::max_order = 1, not fe_type.order = 2 > > Looks like you are trying to have a second order lagrange element on a > Tet4. Try changing to FIRST order on line 117 of ex3. line 119.  John 
From: John Peterson <jwpeterson@gm...>  20090129 23:15:41

On Thu, Jan 29, 2009 at 4:54 PM, Brent Kraczek <bkraczek@...> wrote: > However, when attempting to use this mesh I get the following error > messages: > > > > \begin{verbatim} > ERROR: Finite element LAGRANGE on geometric element TET > only supports FEInterface::max_order = 1, not fe_type.order = 2 Looks like you are trying to have a second order lagrange element on a Tet4. Try changing to FIRST order on line 117 of ex3.  John 
From: Brent Kraczek <bkraczek@ic...>  20090129 22:54:41

Hey all, I believe there is a bug somewhere in the readin portion for .xda files. I have not been able to track it down, but the code having problems. To be sure this wasn't a fixed problem I downloaded the most recent version on the sourceforge svn server today. I generated a tetrahedral mesh using another program and converted it to .xda format using a script, based on the answers benkirk gave to my question about the format. I have attached the file, but here is the header and the first few lines of the connectivity array: \begin{verbatim} libMesh0.7.0+ 1143 # number of elements 222 # number of nodes . # boundary condition specification file n/a # subdomain id specification file n/a # processor id specification file n/a # plevel specification file 1143 # n_elem at level 0, [type (n0 ... nN1) ] 8 85 19 80 93 8 2 1 26 49 8 77 55 58 17 8 44 57 49 15 \end{verbatim} I then used the file in a modified version of example 3 (single processor) which worked just fine in 3d using using \begin{verbatim} MeshTools::Generation::build_cube (mesh, 20, 20, 20, 1., 1., 1., 1., 1., 1., HEX20); \end{verbatim} However, when attempting to use this mesh I get the following error messages: \begin{verbatim} ERROR: Finite element LAGRANGE on geometric element TET only supports FEInterface::max_order = 1, not fe_type.order = 2 WARNING: Finite element LAGRANGE on geometric element TET could not be p refined past FEInterface::max_order = 1 ERROR: unsigned char too small to hold Elem::_p_level! Recompile with Elem:_p_level set to something bigger! [0] /home/bkraczek/codeslnx/libmesh/include/geom/elem.h, line 1574, compiled Jan 29 2009 at 16:23:47 terminate called after throwing an instance of 'libMesh::LogicError' what(): Error in libMesh internal logic Aborted \end{verbatim} What I have found through digging is that when it goes to reinitialize the mesh (DofMap::reinit) it finds that fe_type.order == 2; elem>p_level()==255 . Any help would be appreciated, Brent Kirk, Benjamin (JSCEG) wrote: >> Connectivity: >> The header is followed immediately by the connectivity. Are blank or >> commented lines ignored? (i.e. can I put a blank line anywhere?) >> > > I think so, I'll check... if not I will fix the code because that is a > perfectly reasonable request. Certainly a comment can follow data on a > line, see for example reference_elements/3D/one_hex20.xda > > >> In connectivity section, it appears that the first number is the element >> type. I want to use tetrahedra, so it looks like this number should be 8 >> for a tet4 and 9 for a tet10. The rest of the numbers are the node index >> numbers, starting from zero. >> > > Right. > > >> Nodes: >> Next come the node locations in Cartesian coordinates. Their order >> should correspond to the indices used by the connectivity and the >> possibly the boundary conditions. >> > > Right. > > > >> Boundary conditions (where I have the most questions): >> >> First, is this section necessary if I intend to use the same boundary >> condition on all external elements? In the examples I've been working >> from (primarily #3, which uses a penalty method), the code checks to see >> if the element has a neighbor and applies the BC if it does not. In my >> application I need to use a special mixed ("Robin") BC, so I don't to >> use a pure Dirichlet condition. >> > > Correct. The boundary conditions are only there for your convenience. If > you do not need to > > >> Second, how is the side index determined? Specifically, If I have a >> tetrahedron with arbitrary position in space, how do I know which index >> a side gets? >> > > The side indices is dependent on the node ordering. see for example > src/geom/cell_tet4.C: > > const unsigned int Tet4::side_nodes_map[4][3] = > { > {0, 2, 1}, // Side 0 > {0, 1, 3}, // Side 1 > {1, 2, 3}, // Side 2 > {2, 0, 3} // Side 3 > }; > > So side 0 is the triangle defined by nodes (0,2,1) from the tet. > > > >> Third, how is the number for the boundary condition used? Is this index >> the same as used in something like 'elem>neighbor(side)'? >> > > It is not used at all. It is inserted into the BoundaryInfo object > ('mesh.boundary_info') and you can get access to it to set different BCs on > different parts of the domain. > > Ben > > > 
From: Brent Kraczek <bkraczek@ic...>  20090128 22:24:30

Thank you. Benjamin Kirk answered the questions I had, so I think I know what to do now. Derek Gaston wrote: > Brent... this isn't a great answer... but I usually just look at > xdr_io.C.... the write() method is particularly informative ;) > > Derek > > On Jan 28, 2009, at 1:51 PM, Brent Kraczek wrote: > >> Hi all, >> >> For my application I need a specialized mesh. I have comeup with a way >> to generate the mesh in another format, but it appears I need to convert >> the mesh to the .xda format. This is fine, and I found the 2005 document >> "Description of the XDA/XDR mesh format ..." . However, the reference >> elements included with the most recent version of libmesh don't appear >> to follow this format. Is there a more recent document, possibly an >> internal design doc, or somewhere in the source code that gives an up to >> date description? I think I'm figuring it out, but I want to be sure. >> >> Thanks, >> Brent >> >>  >> >> This SF.net email is sponsored by: >> SourcForge Community >> SourceForge wants to tell your story. >> http://p.sf.net/sfu/sfspreadtheword >> _______________________________________________ >> Libmeshusers mailing list >> Libmeshusers@... >> https://lists.sourceforge.net/lists/listinfo/libmeshusers > 
From: Derek Gaston <friedmud@gm...>  20090128 22:21:29

Brent... this isn't a great answer... but I usually just look at xdr_io.C.... the write() method is particularly informative ;) Derek On Jan 28, 2009, at 1:51 PM, Brent Kraczek wrote: > Hi all, > > For my application I need a specialized mesh. I have comeup with a > way > to generate the mesh in another format, but it appears I need to > convert > the mesh to the .xda format. This is fine, and I found the 2005 > document > "Description of the XDA/XDR mesh format ..." . However, the reference > elements included with the most recent version of libmesh don't appear > to follow this format. Is there a more recent document, possibly an > internal design doc, or somewhere in the source code that gives an > up to > date description? I think I'm figuring it out, but I want to be sure. > > Thanks, > Brent > >  > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sfspreadtheword > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers 
From: John Peterson <peterson@cf...>  20090128 22:05:37

On Wed, Jan 28, 2009 at 2:51 PM, Brent Kraczek <bkraczek@...> wrote: > Hi all, > > For my application I need a specialized mesh. I have comeup with a way > to generate the mesh in another format, but it appears I need to convert > the mesh to the .xda format. This is fine, and I found the 2005 document > "Description of the XDA/XDR mesh format ..." . However, the reference > elements included with the most recent version of libmesh don't appear > to follow this format. Is there a more recent document, possibly an > internal design doc, or somewhere in the source code that gives an up to > date description? I think I'm figuring it out, but I want to be sure. Yes, unfortunately that documentation is outdated! However, I think you can still read in the old style format by using a "legacy" XDA reader object. If you have an svn checkout of the code, you can diff the reference element files against revision 1254, e.g. svn diff r1254 reference_elements/2D/one_quad.xda to see what's changed.  John 
From: Brent Kraczek <bkraczek@ic...>  20090128 20:51:16

Hi all, For my application I need a specialized mesh. I have comeup with a way to generate the mesh in another format, but it appears I need to convert the mesh to the .xda format. This is fine, and I found the 2005 document "Description of the XDA/XDR mesh format ..." . However, the reference elements included with the most recent version of libmesh don't appear to follow this format. Is there a more recent document, possibly an internal design doc, or somewhere in the source code that gives an up to date description? I think I'm figuring it out, but I want to be sure. Thanks, Brent 
From: John Peterson <jwpeterson@gm...>  20090127 18:05:37

On Tue, Jan 27, 2009 at 12:02 PM, Roy Stogner <roystgnr@...> wrote: > > On Tue, 27 Jan 2009, John Peterson wrote: > >> At some point since we set up the new wiki, LabobOgetr, has registered >> an account and posted a bunch of spam. We should probably fix this >> ASAP but I can't get to it at the moment. > > "Can't get to it" == "don't have enough time" or > == "have been locked out by the hacker"? Don't have time. I'm on the consulting desk today and ranger is having filesystem issues. (When isn't it?) > I'll revert the spam, but I don't think I've got any admin access > there for IP banning the spambots. I had an old sysop account and password for the wiki. I'll send them to you offlist if you want to give them a try. The weird thing is, it used to be that only the wikisysop could create accounts, but it appears this guy has created an account for himself somehow?  John 
From: Roy Stogner <roystgnr@ic...>  20090127 18:02:52

On Tue, 27 Jan 2009, John Peterson wrote: > At some point since we set up the new wiki, LabobOgetr, has registered > an account and posted a bunch of spam. We should probably fix this > ASAP but I can't get to it at the moment. "Can't get to it" == "don't have enough time" or == "have been locked out by the hacker"? I'll revert the spam, but I don't think I've got any admin access there for IP banning the spambots.  Roy 
From: John Peterson <jwpeterson@gm...>  20090127 17:48:59

Hey all, At some point since we set up the new wiki, LabobOgetr, has registered an account and posted a bunch of spam. We should probably fix this ASAP but I can't get to it at the moment.  John 
From: Mladen Jurak <jurak@ma...>  20090122 19:07:34

Roy Stogner wrote: > > Would it suffice to have an elem_rate_solution available, which > contained (u_nu_p)/deltat on each variable? I might be adding that > for one of my own applications and to make it simpler to write user > code with nonlinear mass matrices again. >  > Roy > > It would be nice to have "(u_nu_p)/deltat" or "u_p". I would prefer some "elem_old_solution" in DifferentiableSystem class. Mladen 
From: Roy Stogner <roystgnr@ic...>  20090122 19:00:20

On Thu, 22 Jan 2009, Mladen Jurak wrote: > The problem is on the boundary where I need to calculate total > flow in order to complete saturation equation. This boundary flow > can be calculated only by using local mass conservation and in > that way I introduce time derivative into spatial > discretization. My need for old solution comes from this time > derivative, but, perhaps, I could shift these boundary terms > containing (p^new p^old)/dt to mass residual part of the > residual. Would it suffice to have an elem_rate_solution available, which contained (u_nu_p)/deltat on each variable? I might be adding that for one of my own applications and to make it simpler to write user code with nonlinear mass matrices again.  Roy 
From: Mladen Jurak <jurak@ma...>  20090122 18:40:17

Roy Stogner wrote: > Mladen Jurak wrote: > >> I wander about the use of "elem_fixed_solution" in >> "EulerSolver::element_residual" method. Fixed solution is >> set to "theta_solution" and therefore during the call to >> "_system.element_time_derivative" both "elem_fixed_solution" >> and "elem_solution" have the same data. > > Right. > >> It happens to me >> that in "element_time_derivative" I need the solution from the >> preceding time level ("old_elem_solution" in >> "EulerSolver::element_residual"). > > May I ask why? > My use of the library is not standard. I solve compressible twophase flow equations by vertexcentered finite volume method, by using some additional classes (made by David Trujillo from University of Pau). The system in fractional flow formulation is composed of pressure equation which gives the total flow, and saturation equation (of convectiondiffusion type) in which the total flow is used. The problem is on the boundary where I need to calculate total flow in order to complete saturation equation. This boundary flow can be calculated only by using local mass conservation and in that way I introduce time derivative into spatial discretization. My need for old solution comes from this time derivative, but, perhaps, I could shift these boundary terms containing (p^new p^old)/dt to mass residual part of the residual. Sorry for this confusing explanation. >> My question is couldn't "elem_fixed_solution" be set to >> "old_elem_solution" in "EulerSolver::element_residual". Then one >> would have more information while assembling the system. >> I don't see any obstacle, but in the other hand I am not sure that >> I understand well the concept of fixed solution. > > Suppose you've got a system like: > > d(M(u))/dt = F(u) > > A theta method solve, from previous timestep u_p to next timestep u_n > via theta interpolant u_t, might look like: > > (M(u_n)  M(u_p))/deltat = F(u_t) > > And when discretizing in space by taking only the weighted products > against test functions: > > (M(u_n,v)  M(u_p,v))/deltat = F(u_t,v) > > So for most people, all F() needs to evaluate is the derivative at > u_t, not u_p or u_n. > > The reason for adding elem_fixed_solution was, when we wanted to do > some stabilized formulations, we had v = v_c + w(u_f)  the test > function was now a function v(u) of the solution. But that u had to > be fixed  evaluating M(u_n,v(u_n))  M(u_p,v(u_p)) is inconsistent. > To avoid losing secondorder accuracy in CrankNicholson, the obvious > choice for EulerSolver was v(u_f) where u_f = u_t. > > But while that's the right thing to do for EulerSolver, it sounds like > it's incompatible with what you want  hence my "why?" question. The > right thing to do may be to modify a cloned EulerSolver (like I did > with Euler2Solver when I wanted trapezoidal time integration), but > it's impossible to be sure without knowing what you plan to use the > old solution for. >  > Roy > > 
From: Roy Stogner <roystgnr@ic...>  20090122 18:03:07

Mladen Jurak wrote: > I wander about the use of "elem_fixed_solution" in > "EulerSolver::element_residual" method. Fixed solution is > set to "theta_solution" and therefore during the call to > "_system.element_time_derivative" both "elem_fixed_solution" > and "elem_solution" have the same data. Right. > It happens to me > that in "element_time_derivative" I need the solution from the > preceding time level ("old_elem_solution" in > "EulerSolver::element_residual"). May I ask why? > My question is couldn't "elem_fixed_solution" be set to > "old_elem_solution" in "EulerSolver::element_residual". Then one > would have more information while assembling the system. > I don't see any obstacle, but in the other hand I am not sure that > I understand well the concept of fixed solution. Suppose you've got a system like: d(M(u))/dt = F(u) A theta method solve, from previous timestep u_p to next timestep u_n via theta interpolant u_t, might look like: (M(u_n)  M(u_p))/deltat = F(u_t) And when discretizing in space by taking only the weighted products against test functions: (M(u_n,v)  M(u_p,v))/deltat = F(u_t,v) So for most people, all F() needs to evaluate is the derivative at u_t, not u_p or u_n. The reason for adding elem_fixed_solution was, when we wanted to do some stabilized formulations, we had v = v_c + w(u_f)  the test function was now a function v(u) of the solution. But that u had to be fixed  evaluating M(u_n,v(u_n))  M(u_p,v(u_p)) is inconsistent. To avoid losing secondorder accuracy in CrankNicholson, the obvious choice for EulerSolver was v(u_f) where u_f = u_t. But while that's the right thing to do for EulerSolver, it sounds like it's incompatible with what you want  hence my "why?" question. The right thing to do may be to modify a cloned EulerSolver (like I did with Euler2Solver when I wanted trapezoidal time integration), but it's impossible to be sure without knowing what you plan to use the old solution for.  Roy 
From: Mladen Jurak <jurak@ma...>  20090122 17:48:20

Hi, I wander about the use of "elem_fixed_solution" in "EulerSolver::element_residual" method. Fixed solution is set to "theta_solution" and therefore during the call to "_system.element_time_derivative" both "elem_fixed_solution" and "elem_solution" have the same data. It happens to me that in "element_time_derivative" I need the solution from the preceding time level ("old_elem_solution" in "EulerSolver::element_residual"). My question is couldn't "elem_fixed_solution" be set to "old_elem_solution" in "EulerSolver::element_residual". Then one would have more information while assembling the system. I don't see any obstacle, but in the other hand I am not sure that I understand well the concept of fixed solution. Thanks, Mladen 
From: Derek Gaston <friedmud@gm...>  20090121 22:23:58

On Jan 21, 2009, at 2:56 PM, Roy Stogner wrote: > If all these systems are on the same mesh, no communication should be > necessary. You'll still have to use PETSc APIs, but the existing > NumericVector::insert() interface might suffice and stay > Trilinoscompatible. Right. They are on the same mesh (all of the systems are part of the same EquationSystems object).... and there won't be any parallel communication. >> > Not if you do the insert()s element by element. (or > elementbyelement for elem dofs and node by node for node dofs) For now... I only have nodal degrees of freedom (no real plans to use nonlagrange elements at the current time). So you're saying I can do a node loop and call node.dof_number(system, var, 0) (0 since I'm using Lagrange) to get the dof_number for that variable in each system.... then just do the copy. That's really not bad... and pretty straight forward. I suppose I will need to check to make sure that that dof_number is owned by the local processor... but that's not a big deal. I guess I can just check the processor_id() of the node to see if it corresponds to the local processor id before I lookup the dof_numbers... I'll probably switch to this... what I'm doing does work... but is Petsc specific.... and has some fragility built in. >> > If I was doing this, I'd first extend System::project_vector() to take > a variable specifying projection of only one variable at a time, then > if I was worried about efficiency I'd add another overload replacing > fptr and gptr with identification of another system and variable so as > to avoid the MeshFunction construction and octree lookups. But that > would only count as an easier way if it already existed, and "better" > depends on whether you like or dislike "more flexible and less > efficient". Hmmm.... I don't know about this. The straight forward method above sounds like the way to go. Thanks! Derek 
From: Roy Stogner <roystgnr@ic...>  20090121 22:12:02

On Wed, 21 Jan 2009, Derek Gaston wrote: > So, I have one big coupled implicit system.... and then a smaller > implicit system for each variable in the coupled system. I need to > copy the entries from the RHS vector for the big system that > correspond to one variable into the RHS vector for the small system... > > Looking around it appears as though Petsc's VecScatter is exactly what > I want.... it takes a list of indices to copy from and to... the > problem I'm having is with the indices. If all these systems are on the same mesh, no communication should be necessary. You'll still have to use PETSc APIs, but the existing NumericVector::insert() interface might suffice and stay Trilinoscompatible. > Obviously the dof_indices (of each system) are both what I want to > copy from and too.... but they are only defined in the context of one > element... I really need to have the global list of all of the > dof_indices for a variable. Not if you do the insert()s element by element. (or elementbyelement for elem dofs and node by node for node dofs) > Finally: am I going about this all wrong? Is there a better (easier) > way? If I was doing this, I'd first extend System::project_vector() to take a variable specifying projection of only one variable at a time, then if I was worried about efficiency I'd add another overload replacing fptr and gptr with identification of another system and variable so as to avoid the MeshFunction construction and octree lookups. But that would only count as an easier way if it already existed, and "better" depends on whether you like or dislike "more flexible and less efficient".  Roy 
From: Derek Gaston <friedmud@gm...>  20090121 21:26:09

In working on this... it turns out that you don't have to do the allgather(). Petsc has a distributed index list... which is what the scatters work on. So each processor only adds it's indices to be copied. So far VecScatter is working well for just one variable... now to see how it goes for 2. Derek On Wed, Jan 21, 2009 at 2:12 PM, Derek Gaston <friedmud@...> wrote: > So, I have one big coupled implicit system.... and then a smaller implicit > system for each variable in the coupled system. I need to copy the entries > from the RHS vector for the big system that correspond to one variable into > the RHS vector for the small system... > > Looking around it appears as though Petsc's VecScatter is exactly what I > want.... it takes a list of indices to copy from and to... the problem I'm > having is with the indices. > > Obviously the dof_indices (of each system) are both what I want to copy > from and too.... but they are only defined in the context of one element... > I really need to have the global list of all of the dof_indices for a > variable. > > I could use the System::local_dof_indices() function I added... which > returns the set of all the local dofs... and then copy it out to a > std::vector and use parallel::allgather() to get the global list of dofs. > > The problem I'm having with all of this is ordering. When i get the > std::set of local dofs... they are going to be sorted. My question is: is > it true that (for instance) the smallest dof_index for a variable in one > system will correspond to the smallest dof index for that same variable in > another system? > > Say for instance you have variables u and v.... you create one implicit > system (named "Ben") with _both_ variables in it and 2 more implicit systems > ("John" and "Roy").... where you just add one variable (either u or v) to > each system. > > Will the smallest dof_index for u in "Ben" always correspond to the > smallest dof_index for u in "John"? More generally, will the ordering of > dofs correspond between the two systems? > > Finally: am I going about this all wrong? Is there a better (easier) way? > > Thanks, > Derek > 
From: Derek Gaston <friedmud@gm...>  20090121 21:13:23

So, I have one big coupled implicit system.... and then a smaller implicit system for each variable in the coupled system. I need to copy the entries from the RHS vector for the big system that correspond to one variable into the RHS vector for the small system... Looking around it appears as though Petsc's VecScatter is exactly what I want.... it takes a list of indices to copy from and to... the problem I'm having is with the indices. Obviously the dof_indices (of each system) are both what I want to copy from and too.... but they are only defined in the context of one element... I really need to have the global list of all of the dof_indices for a variable. I could use the System::local_dof_indices() function I added... which returns the set of all the local dofs... and then copy it out to a std::vector and use parallel::allgather() to get the global list of dofs. The problem I'm having with all of this is ordering. When i get the std::set of local dofs... they are going to be sorted. My question is: is it true that (for instance) the smallest dof_index for a variable in one system will correspond to the smallest dof index for that same variable in another system? Say for instance you have variables u and v.... you create one implicit system (named "Ben") with _both_ variables in it and 2 more implicit systems ("John" and "Roy").... where you just add one variable (either u or v) to each system. Will the smallest dof_index for u in "Ben" always correspond to the smallest dof_index for u in "John"? More generally, will the ordering of dofs correspond between the two systems? Finally: am I going about this all wrong? Is there a better (easier) way? Thanks, Derek 
From: Roy Stogner <roystgnr@ic...>  20090121 13:30:58

On Wed, 21 Jan 2009, yunfei zhu wrote: > I am using the 0.6.3rcl version of libmesh. and found that I can not use > equation_systems.read() to read in a NonlinearImplicitSystem, I also noted > that this has been fixed in trunk version. > I would like to use the latest version of libmesh and want to download the > trunk version. Because the only way I could do is to click on each file > then save it, but there are so many files to be dowload, so there must be > some other better way to download all the files together. could you please > tell me how to download the trunk version easily? Thanks in advance. See the Download section of the webpage: "svn checkout https://libmesh.svn.sourceforge.net/svnroot/libmesh/trunk/libmesh "  Roy 
From: yunfei zhu <yzhu2009@go...>  20090121 13:09:44

Hi, I am using the 0.6.3rcl version of libmesh. and found that I can not use equation_systems.read() to read in a NonlinearImplicitSystem, I also noted that this has been fixed in trunk version. I would like to use the latest version of libmesh and want to download the trunk version. Because the only way I could do is to click on each file then save it, but there are so many files to be dowload, so there must be some other better way to download all the files together. could you please tell me how to download the trunk version easily? Thanks in advance. yunfei 
From: Tim Kroeger <tim.kroeger@ce...>  20090121 07:42:37

On Tue, 20 Jan 2009, Roy Stogner wrote: > On Tue, 20 Jan 2009, Tim Kroeger wrote: > >> Well, there is a problem. That is, it doesn't work. The attached test >> application hangs up in the second refinement step. (It runs perfectly if >> the edge_level_mismatch_limit() line is removed.) > > I've just committed a fix to SVN if you want to give it a try. Works great now, thank you very much. > Speaking of broken code, though, could you try ex20 with your > PetscVector patch? I just tried to do that right now, but I thought I'd just do "svn update" before, and this turned out to fix my bug, because you have already checked in my patch and your bugfix of it. Hence it works now. (: > It seems to be breaking for me on the fromVec > constructor, which appears to assume that all parallel vectors have > ghost mappings. Well, I thought for a parallel vector without ghost dofs, Vec::mapping>n would be equal to the result of VecGetLocalSize(), hence my code would work as expected. If the truth is that in that case Vec::mapping is a NULL pointer, then of course my code would crash. > While that's the eventual goal for all parallel petsc > vectors created by the library, I'd like to keep the current > lessefficient vectors working too, to support usercreated vectors > using the old API and to make testing easier as we switch to the new > vectors. Of course that's right. > I can fix the copy constructor easily enough, but if there's > any other places you might have made the same assumption (or if you > can't replicate the problem or if you think I've misdiagnosed it), let > me know. There is no other place I made the assumption mentioned above. Hence, everything might be fine now. Best Regards, Tim  Dr. Tim Kroeger tim.kroeger@... Phone +494212187710 tim.kroeger@... Fax +494212184236 Fraunhofer MEVIS, Institute for Medical Image Computing Universitaetsallee 29, 28359 Bremen, Germany 
From: Roy Stogner <roystgnr@ic...>  20090120 17:55:06

On Tue, 20 Jan 2009, Tim Kroeger wrote: >> I'm not sure how thoroughly the nondefault options have been tested; >> let us know if there seem to be any problems. > > Well, there is a problem. That is, it doesn't work. The attached test > application hangs up in the second refinement step. (It runs perfectly if > the edge_level_mismatch_limit() line is removed.) Ah, yes. Instead of "how thoroughly", I probably should have said "if". IIRC I once had to rewrite face_level_mismatch_limit() to work with ParallelMesh, and I figured I'd throw in an option for edge_level_mismatch_limit() in case anyone ever wanted to use it. You must be the first, because it's been broken from the start. I've just committed a fix to SVN if you want to give it a try. Speaking of broken code, though, could you try ex20 with your PetscVector patch? It seems to be breaking for me on the fromVec constructor, which appears to assume that all parallel vectors have ghost mappings. While that's the eventual goal for all parallel petsc vectors created by the library, I'd like to keep the current lessefficient vectors working too, to support usercreated vectors using the old API and to make testing easier as we switch to the new vectors. I can fix the copy constructor easily enough, but if there's any other places you might have made the same assumption (or if you can't replicate the problem or if you think I've misdiagnosed it), let me know.  Roy 