### Email Archive: libmesh-users (read-only)

 Re: [Libmesh-users] Neumann condition implementation From: Roy Stogner - 2008-06-01 14:48 ```On Sun, 1 Jun 2008, Maxime Debon wrote: > Trying to implement a Neumann condition at the upper boundary of a 1D > transient problem, I am facing an interesting case. In fact, changing > the size of the domain, modifying the value Xmax of the upper > boundary, alters the result. > > //-------------------------------------------------------// > for (unsigned int i=0; i { > Number valueNeumann= 1.0; > Fe(i) += JxW_face[qp]*valueNeumann*phi_face[i][qp]; > } > //-------------------------------------------------------// > > To illustrate, the value of the first derivative at the boundary is > effectively 1.0 only when the value of Xmax is 133.3333. Elsewhere, > the derivative is too small when Xmax > 133.33 and to big when Xmax < > 133.33. > Using a second order Lagrange element, I may forget a correction term > to evaluate the surface integral. No correction term should be needed; libMesh should get phi_face right regardless of what element type you use. But my first question would be: are you sure the solution is sufficiently converged? Remember, Neumann conditions are only enforced weakly, so if you try to impose a boundary derivative of 1.0 this way, all you'll get is a formulation whose boundary derivative converges to 1.0 as your mesh size goes to zero. On coarser meshes, the finite element formulation can satisfy the boundary condition less accurately as part of an attempt to simultaneously satisfy the interior PDE more accurately. It's possible that your magic number of Xmax = 400/3 is just a fluke that gives you superconvergence at the boundary for your PDE and mesh. If I haven't correctly guessed what the problem is, could you boil it down to a short test case for us? --- Roy ```

[Libmesh-users] rpc/rpc.h usability and other problems Dmitry Matison <matison.d@me...>
 Re: [Libmesh-users] rpc/rpc.h usability and other problems From: John Peterson - 2008-05-30 16:57 ```Hi, I haven't personally seen these errors before. I might take a look into the autoconf documentation as is suggested and see if anything promising pops up. As to your other problem, I don't see anything particularly sinister about line 389 of the type_vector.h file (in the SVN head). I'll take a look at the 0.6.2 version momentarily and see if anything else pops out. In the meantime, you should probably compile in debug mode in order to see if any asserts are tripped before the code just dies on you. We don't have much to go on with your error message. -J On Fri, May 30, 2008 at 11:42 AM, Dmitry Matison wrote: > Hello! > I'm using libmesh via cygwin and have a problem with configure procedure. > Have someone handled with these errors? > > checking dlfcn.h usability... no >> checking dlfcn.h presence... yes >> configure: WARNING: dlfcn.h: present but cannot be compiled >> configure: WARNING: dlfcn.h: check for missing prerequisite headers? >> configure: WARNING: dlfcn.h: see the Autoconf documentation >> configure: WARNING: dlfcn.h: section "Present But Cannot Be Compiled" >> configure: WARNING: dlfcn.h: proceeding with the preprocessor's result >> configure: WARNING: dlfcn.h: in the future, the compiler will take >> precedence >> configure: WARNING: ## ------------------------------------------ ## >> configure: WARNING: ## Report this to the AC_PACKAGE_NAME lists. ## >> configure: WARNING: ## ------------------------------------------ ## >> checking for dlfcn.h... yes >> >> checking rpc/rpc.h usability... no >> checking rpc/rpc.h presence... yes >> configure: WARNING: rpc/rpc.h: present but cannot be compiled >> configure: WARNING: rpc/rpc.h: check for missing prerequisite headers? >> configure: WARNING: rpc/rpc.h: see the Autoconf documentation >> configure: WARNING: rpc/rpc.h: section "Present But Cannot Be Compiled" >> configure: WARNING: rpc/rpc.h: proceeding with the preprocessor's result >> configure: WARNING: rpc/rpc.h: in the future, the compiler will take >> precedence >> configure: WARNING: ## ------------------------------------------ ## >> configure: WARNING: ## Report this to the AC_PACKAGE_NAME lists. ## >> configure: WARNING: ## ------------------------------------------ ## >> checking for rpc/rpc.h... yes >> checking for xdrstdio_create... no > > > Another problem is that I can't run the examples because of these errors: > > \$ ./ex0-opt.exe >> [0] /cygdrive/d/projects/vs/libmesh-0.6.2/include/numerics/type_vector.h, >> line 389, compiled May 29 >> 2008 at 18:30:27 >> Aborted (core dumped) > > > > >> \$ ./ex4-opt -d 1 -n 20 >> Running ./ex4-opt -d 1 -n 20 >> >> Mesh Information: >> mesh_dimension()=1 >> spatial_dimension()=2 >> n_nodes()=41 >> n_elem()=20 >> n_local_elem()=20 >> n_active_elem()=20 >> n_subdomains()=1 >> n_processors()=1 >> processor_id()=0 >> >> EquationSystems >> n_systems()=1 >> System "Poisson" >> Type "LinearImplicit" >> Variables="u" >> Finite Element Types="LAGRANGE", "JACOBI_20_00" >> Infinite Element Mapping="CARTESIAN" >> Approximation Orders="SECOND", "THIRD" >> n_dofs()=41 >> n_local_dofs()=41 >> n_constrained_dofs()=0 >> n_vectors()=1 >> >> [0] /cygdrive/d/projects/vs/libmesh-0.6.2/include/numerics/type_vector.h, >> line 389, compiled May 29 >> 2008 at 18:30:27 >> Aborted (core dumped) >> > > > \$ ./ex6-opt >> Running ex6 with dim = 3 >> >> [0] /cygdrive/d/projects/vs/libmesh-0.6.2/include/numerics/type_vector.h, >> line 389, compiled May 29 >> 2008 at 18:25:18 >> 11 [sig] ex6-opt 1088 >> d:\projects\vs\libmesh-0.6.2\examples\ex6\ex6-opt.exe: *** fatal error - >> called with threadlist_ix -1 >> Hangup > > > Regards, > Matison Dmitry, > student, Department of Applied Mathematics, > Moscow Engineering Physics Institute (State University). > ------------------------------------------------------------------------- > 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/ > _______________________________________________ > Libmesh-users mailing list > Libmesh-users@... > https://lists.sourceforge.net/lists/listinfo/libmesh-users > ```

 Re: [Libmesh-users] rpc/rpc.h usability and other problems From: Roy Stogner - 2008-05-30 17:07 ```On Fri, 30 May 2008, Dmitry Matison wrote: > I'm using libmesh via cygwin and have a problem with configure procedure. > Have someone handled with these errors? > > checking dlfcn.h usability... no >> checking dlfcn.h presence... yes >> configure: WARNING: dlfcn.h: present but cannot be compiled >> configure: WARNING: dlfcn.h: check for missing prerequisite headers? >> configure: WARNING: dlfcn.h: see the Autoconf documentation >> configure: WARNING: dlfcn.h: section "Present But Cannot Be Compiled" >> configure: WARNING: dlfcn.h: proceeding with the preprocessor's result >> configure: WARNING: dlfcn.h: in the future, the compiler will take >> precedence >> configure: WARNING: ## ------------------------------------------ ## >> configure: WARNING: ## Report this to the AC_PACKAGE_NAME lists. ## >> configure: WARNING: ## ------------------------------------------ ## >> checking for dlfcn.h... yes If configure doesn't find a workable dlfcn.h header, it shouldn't matter for most users - "print_trace()" support will be turned off, but that's just an internal utility function that makes parallel debugging on Linux a bit easier. I'm not *too* surprised if the underlying functions aren't fully supported by cygwin. >> checking rpc/rpc.h usability... no >> checking rpc/rpc.h presence... yes >> configure: WARNING: rpc/rpc.h: present but cannot be compiled >> configure: WARNING: rpc/rpc.h: check for missing prerequisite headers? >> configure: WARNING: rpc/rpc.h: see the Autoconf documentation >> configure: WARNING: rpc/rpc.h: section "Present But Cannot Be Compiled" >> configure: WARNING: rpc/rpc.h: proceeding with the preprocessor's result >> configure: WARNING: rpc/rpc.h: in the future, the compiler will take >> precedence >> configure: WARNING: ## ------------------------------------------ ## >> configure: WARNING: ## Report this to the AC_PACKAGE_NAME lists. ## >> configure: WARNING: ## ------------------------------------------ ## >> checking for rpc/rpc.h... yes >> checking for xdrstdio_create... no This is more annoying (lack of a good rpc.h header means .xdr file support will be disabled!), but until you figure out why configure doesn't think your rpc.h header works, you can always use .xda files instead; they're just the ASCII version of the same format. > Another problem is that I can't run the examples because of these errors: > > \$ ./ex0-opt.exe >> [0] /cygdrive/d/projects/vs/libmesh-0.6.2/include/numerics/type_vector.h, >> line 389, compiled May 29 >> 2008 at 18:30:27 >> Aborted (core dumped) This is an unrelated problem. Take a look at line 389 of type_vector.h; it's basically complaining that some code is trying to access the z coordinate of a space vector when the library's been compiled to use two spatial dimensions. If you've set DIM to something other than 3 (e.g. by editing libmesh_common.h, or configuring with --enable-2D-only), then set it back for now, and we'll try to replicate and fix the problem before the next release. If you haven't set DIM to something other than 3 intentionally, then there must be some other definition of DIM coming in through cygwin or other third party headers; I'm not sure what the best way to quickly fix that would be. In the long run: Ben, John, should we switch that preprocessor variable name to "LIBMESH_DIM"? Even if it's not conflicting with someone else's names now, it's such a short natural name that it's bound to conflict with something else eventually. --- Roy ```

 Re: [Libmesh-users] rpc/rpc.h usability and other problems From: John Peterson - 2008-05-30 17:07 ```On Fri, May 30, 2008 at 11:56 AM, John Peterson wrote: > Hi, > > I haven't personally seen these errors before. I might take a look > into the autoconf documentation as is suggested and see if anything > promising pops up. > > As to your other problem, I don't see anything particularly sinister > about line 389 of the type_vector.h file (in the SVN head). I'll take > a look at the 0.6.2 version momentarily and see if anything else pops > out. OK, I take that back. In 0.6.2 that line is an error() which can only occur if the code has been compiled with DIM < 3. This is likely a bug on our part, because we rarely compile with DIM=2, which I assume you did? A quick fix might be to re-configure with DIM=3 and see if the seg-fault goes away. -J > > > > On Fri, May 30, 2008 at 11:42 AM, Dmitry Matison wrote: >> Hello! >> I'm using libmesh via cygwin and have a problem with configure procedure. >> Have someone handled with these errors? >> >> checking dlfcn.h usability... no >>> checking dlfcn.h presence... yes >>> configure: WARNING: dlfcn.h: present but cannot be compiled >>> configure: WARNING: dlfcn.h: check for missing prerequisite headers? >>> configure: WARNING: dlfcn.h: see the Autoconf documentation >>> configure: WARNING: dlfcn.h: section "Present But Cannot Be Compiled" >>> configure: WARNING: dlfcn.h: proceeding with the preprocessor's result >>> configure: WARNING: dlfcn.h: in the future, the compiler will take >>> precedence >>> configure: WARNING: ## ------------------------------------------ ## >>> configure: WARNING: ## Report this to the AC_PACKAGE_NAME lists. ## >>> configure: WARNING: ## ------------------------------------------ ## >>> checking for dlfcn.h... yes >>> >>> checking rpc/rpc.h usability... no >>> checking rpc/rpc.h presence... yes >>> configure: WARNING: rpc/rpc.h: present but cannot be compiled >>> configure: WARNING: rpc/rpc.h: check for missing prerequisite headers? >>> configure: WARNING: rpc/rpc.h: see the Autoconf documentation >>> configure: WARNING: rpc/rpc.h: section "Present But Cannot Be Compiled" >>> configure: WARNING: rpc/rpc.h: proceeding with the preprocessor's result >>> configure: WARNING: rpc/rpc.h: in the future, the compiler will take >>> precedence >>> configure: WARNING: ## ------------------------------------------ ## >>> configure: WARNING: ## Report this to the AC_PACKAGE_NAME lists. ## >>> configure: WARNING: ## ------------------------------------------ ## >>> checking for rpc/rpc.h... yes >>> checking for xdrstdio_create... no >> >> >> Another problem is that I can't run the examples because of these errors: >> >> \$ ./ex0-opt.exe >>> [0] /cygdrive/d/projects/vs/libmesh-0.6.2/include/numerics/type_vector.h, >>> line 389, compiled May 29 >>> 2008 at 18:30:27 >>> Aborted (core dumped) >> >> >> >> >>> \$ ./ex4-opt -d 1 -n 20 >>> Running ./ex4-opt -d 1 -n 20 >>> >>> Mesh Information: >>> mesh_dimension()=1 >>> spatial_dimension()=2 >>> n_nodes()=41 >>> n_elem()=20 >>> n_local_elem()=20 >>> n_active_elem()=20 >>> n_subdomains()=1 >>> n_processors()=1 >>> processor_id()=0 >>> >>> EquationSystems >>> n_systems()=1 >>> System "Poisson" >>> Type "LinearImplicit" >>> Variables="u" >>> Finite Element Types="LAGRANGE", "JACOBI_20_00" >>> Infinite Element Mapping="CARTESIAN" >>> Approximation Orders="SECOND", "THIRD" >>> n_dofs()=41 >>> n_local_dofs()=41 >>> n_constrained_dofs()=0 >>> n_vectors()=1 >>> >>> [0] /cygdrive/d/projects/vs/libmesh-0.6.2/include/numerics/type_vector.h, >>> line 389, compiled May 29 >>> 2008 at 18:30:27 >>> Aborted (core dumped) >>> >> >> >> \$ ./ex6-opt >>> Running ex6 with dim = 3 >>> >>> [0] /cygdrive/d/projects/vs/libmesh-0.6.2/include/numerics/type_vector.h, >>> line 389, compiled May 29 >>> 2008 at 18:25:18 >>> 11 [sig] ex6-opt 1088 >>> d:\projects\vs\libmesh-0.6.2\examples\ex6\ex6-opt.exe: *** fatal error - >>> called with threadlist_ix -1 >>> Hangup >> >> >> Regards, >> Matison Dmitry, >> student, Department of Applied Mathematics, >> Moscow Engineering Physics Institute (State University). >> ------------------------------------------------------------------------- >> 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/ >> _______________________________________________ >> Libmesh-users mailing list >> Libmesh-users@... >> https://lists.sourceforge.net/lists/listinfo/libmesh-users >> > ```

 Re: [Libmesh-users] rpc/rpc.h usability and other problems From: John Peterson - 2008-05-30 17:13 ```On Fri, May 30, 2008 at 12:06 PM, Roy Stogner wrote: > > On Fri, 30 May 2008, Dmitry Matison wrote: > >> I'm using libmesh via cygwin and have a problem with configure procedure. >> Have someone handled with these errors? >> >> checking dlfcn.h usability... no >>> checking dlfcn.h presence... yes >>> configure: WARNING: dlfcn.h: present but cannot be compiled >>> configure: WARNING: dlfcn.h: check for missing prerequisite headers? >>> configure: WARNING: dlfcn.h: see the Autoconf documentation >>> configure: WARNING: dlfcn.h: section "Present But Cannot Be Compiled" >>> configure: WARNING: dlfcn.h: proceeding with the preprocessor's result >>> configure: WARNING: dlfcn.h: in the future, the compiler will take >>> precedence >>> configure: WARNING: ## ------------------------------------------ ## >>> configure: WARNING: ## Report this to the AC_PACKAGE_NAME lists. ## >>> configure: WARNING: ## ------------------------------------------ ## >>> checking for dlfcn.h... yes > > If configure doesn't find a workable dlfcn.h header, it shouldn't > matter for most users - "print_trace()" support will be turned off, > but that's just an internal utility function that makes parallel > debugging on Linux a bit easier. I'm not *too* surprised if the > underlying functions aren't fully supported by cygwin. > >>> checking rpc/rpc.h usability... no >>> checking rpc/rpc.h presence... yes >>> configure: WARNING: rpc/rpc.h: present but cannot be compiled >>> configure: WARNING: rpc/rpc.h: check for missing prerequisite headers? >>> configure: WARNING: rpc/rpc.h: see the Autoconf documentation >>> configure: WARNING: rpc/rpc.h: section "Present But Cannot Be Compiled" >>> configure: WARNING: rpc/rpc.h: proceeding with the preprocessor's result >>> configure: WARNING: rpc/rpc.h: in the future, the compiler will take >>> precedence >>> configure: WARNING: ## ------------------------------------------ ## >>> configure: WARNING: ## Report this to the AC_PACKAGE_NAME lists. ## >>> configure: WARNING: ## ------------------------------------------ ## >>> checking for rpc/rpc.h... yes >>> checking for xdrstdio_create... no > > This is more annoying (lack of a good rpc.h header means .xdr file > support will be disabled!), but until you figure out why configure > doesn't think your rpc.h header works, you can always use .xda files > instead; they're just the ASCII version of the same format. > >> Another problem is that I can't run the examples because of these errors: >> >> \$ ./ex0-opt.exe >>> [0] /cygdrive/d/projects/vs/libmesh-0.6.2/include/numerics/type_vector.h, >>> line 389, compiled May 29 >>> 2008 at 18:30:27 >>> Aborted (core dumped) > > This is an unrelated problem. Take a look at line 389 of > type_vector.h; it's basically complaining that some code is trying to > access the z coordinate of a space vector when the library's been > compiled to use two spatial dimensions. If you've set DIM to > something other than 3 (e.g. by editing libmesh_common.h, or > configuring with --enable-2D-only), then set it back for now, and > we'll try to replicate and fix the problem before the next release. > If you haven't set DIM to something other than 3 intentionally, then > there must be some other definition of DIM coming in through cygwin or > other third party headers; I'm not sure what the best way to quickly > fix that would be. Ooops, Roy was a bit faster than me... > In the long run: Ben, John, should we switch that preprocessor > variable name to "LIBMESH_DIM"? Even if it's not conflicting with > someone else's names now, it's such a short natural name that it's > bound to conflict with something else eventually. Sounds like a good plan, along the lines of your changes of error() -> libmesh_error(), etc. While we're at it, should we also consider similar changes for the other #defines in libmesh_config.h? For example, all the HAVE_LIBRARYFOO would become LIBMESH_HAVE_LIBRARYFOO, etc. Granted, these are less likely than DIM to trip over other libraries but as the library gets more mature I think this is a natural progression... -J ```

 Re: [Libmesh-users] rpc/rpc.h usability and other problems From: Roy Stogner - 2008-05-30 17:33 ```> Sounds like a good plan, along the lines of your changes of error() -> > libmesh_error(), etc. While we're at it, should we also consider > similar changes for the other #defines in libmesh_config.h? For > example, all the HAVE_LIBRARYFOO would become LIBMESH_HAVE_LIBRARYFOO, > etc. Granted, these are less likely than DIM to trip over other > libraries but as the library gets more mature I think this is a > natural progression... Not a bad idea. We'd also stick some temporary lines like: #define HAVE_LIBRARYFOO LIBMESH_HAVE_LIBRARYFOO at the bottom of libmesh_config.h? Just something for 0.6.9 to be removed in 0.7.0, like the current error() macro. I don't see any good way to give a deprecated() type warning to applications that still use the old macros, but we could at least give users a little bit of forwards/backwards compatibility so that anyone using such macros in their own code doesn't have to change application code at the *exact* same time as they upgrade the library. --- Roy ```

 Re: [Libmesh-users] rpc/rpc.h usability and other problems From: Dmitry Matison - 2008-05-30 17:55 ```Thanks for your help, Jonh and Roy! I've tried to configure with these options DIM=3 --enable-2D-only=no\, (was --enable-2D-only=no) but the errors remain. 2008/5/30 John Peterson : > On Fri, May 30, 2008 at 11:56 AM, John Peterson > wrote: > > Hi, > > > > I haven't personally seen these errors before. I might take a look > > into the autoconf documentation as is suggested and see if anything > > promising pops up. > > > > As to your other problem, I don't see anything particularly sinister > > about line 389 of the type_vector.h file (in the SVN head). I'll take > > a look at the 0.6.2 version momentarily and see if anything else pops > > out. > > OK, I take that back. > > In 0.6.2 that line is an error() which can only occur if the code has > been compiled with DIM < 3. This is likely a bug on our part, because > we rarely compile with DIM=2, which I assume you did? A quick fix > might be to re-configure with DIM=3 and see if the seg-fault goes > away. > > -J > > > > > > > > > > On Fri, May 30, 2008 at 11:42 AM, Dmitry Matison > wrote: > >> Hello! > >> I'm using libmesh via cygwin and have a problem with configure > procedure. > >> Have someone handled with these errors? > >> > >> checking dlfcn.h usability... no > >>> checking dlfcn.h presence... yes > >>> configure: WARNING: dlfcn.h: present but cannot be compiled > >>> configure: WARNING: dlfcn.h: check for missing prerequisite > headers? > >>> configure: WARNING: dlfcn.h: see the Autoconf documentation > >>> configure: WARNING: dlfcn.h: section "Present But Cannot Be > Compiled" > >>> configure: WARNING: dlfcn.h: proceeding with the preprocessor's result > >>> configure: WARNING: dlfcn.h: in the future, the compiler will take > >>> precedence > >>> configure: WARNING: ## ------------------------------------------ > ## > >>> configure: WARNING: ## Report this to the AC_PACKAGE_NAME lists. > ## > >>> configure: WARNING: ## ------------------------------------------ > ## > >>> checking for dlfcn.h... yes > >>> > >>> checking rpc/rpc.h usability... no > >>> checking rpc/rpc.h presence... yes > >>> configure: WARNING: rpc/rpc.h: present but cannot be compiled > >>> configure: WARNING: rpc/rpc.h: check for missing prerequisite > headers? > >>> configure: WARNING: rpc/rpc.h: see the Autoconf documentation > >>> configure: WARNING: rpc/rpc.h: section "Present But Cannot Be > Compiled" > >>> configure: WARNING: rpc/rpc.h: proceeding with the preprocessor's > result > >>> configure: WARNING: rpc/rpc.h: in the future, the compiler will take > >>> precedence > >>> configure: WARNING: ## ------------------------------------------ > ## > >>> configure: WARNING: ## Report this to the AC_PACKAGE_NAME lists. > ## > >>> configure: WARNING: ## ------------------------------------------ > ## > >>> checking for rpc/rpc.h... yes > >>> checking for xdrstdio_create... no > >> > >> > >> Another problem is that I can't run the examples because of these > errors: > >> > >> \$ ./ex0-opt.exe > >>> [0] > /cygdrive/d/projects/vs/libmesh-0.6.2/include/numerics/type_vector.h, > >>> line 389, compiled May 29 > >>> 2008 at 18:30:27 > >>> Aborted (core dumped) > >> > >> > >> > >> > >>> \$ ./ex4-opt -d 1 -n 20 > >>> Running ./ex4-opt -d 1 -n 20 > >>> > >>> Mesh Information: > >>> mesh_dimension()=1 > >>> spatial_dimension()=2 > >>> n_nodes()=41 > >>> n_elem()=20 > >>> n_local_elem()=20 > >>> n_active_elem()=20 > >>> n_subdomains()=1 > >>> n_processors()=1 > >>> processor_id()=0 > >>> > >>> EquationSystems > >>> n_systems()=1 > >>> System "Poisson" > >>> Type "LinearImplicit" > >>> Variables="u" > >>> Finite Element Types="LAGRANGE", "JACOBI_20_00" > >>> Infinite Element Mapping="CARTESIAN" > >>> Approximation Orders="SECOND", "THIRD" > >>> n_dofs()=41 > >>> n_local_dofs()=41 > >>> n_constrained_dofs()=0 > >>> n_vectors()=1 > >>> > >>> [0] > /cygdrive/d/projects/vs/libmesh-0.6.2/include/numerics/type_vector.h, > >>> line 389, compiled May 29 > >>> 2008 at 18:30:27 > >>> Aborted (core dumped) > >>> > >> > >> > >> \$ ./ex6-opt > >>> Running ex6 with dim = 3 > >>> > >>> [0] > /cygdrive/d/projects/vs/libmesh-0.6.2/include/numerics/type_vector.h, > >>> line 389, compiled May 29 > >>> 2008 at 18:25:18 > >>> 11 [sig] ex6-opt 1088 > >>> d:\projects\vs\libmesh-0.6.2\examples\ex6\ex6-opt.exe: *** fatal error > - > >>> called with threadlist_ix -1 > >>> Hangup > >> > >> > >> Regards, > >> Matison Dmitry, > >> student, Department of Applied Mathematics, > >> Moscow Engineering Physics Institute (State University). > >> > ------------------------------------------------------------------------- > >> 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/ > >> _______________________________________________ > >> Libmesh-users mailing list > >> Libmesh-users@... > >> https://lists.sourceforge.net/lists/listinfo/libmesh-users > >> > > > ```

 Re: [Libmesh-users] rpc/rpc.h usability and other problems From: Roy Stogner - 2008-05-30 18:03 ```On Fri, 30 May 2008, Dmitry Matison wrote: > Thanks for your help, Jonh and Roy! > I've tried to configure with these options DIM=3 --enable-2D-only=no\, > (was --enable-2D-only=no) > but the errors remain. --enable-2D-only should be off by default; if you didn't turn it on intentionally, then your code must be picking up a bad DIM somewhere else. Let's see if we can just override it for now. In libmesh_common.h, there are the following lines: // 3D spatial dimension unless otherwise specified #ifndef DIM # define DIM 3 #endif Replace them with this: // 3D spatial dimension unless otherwise specified #undef DIM #define DIM 3 That's not likely to be a relible fix, since it depends on libmesh_common.h being included *after* whatever cygwin header already defined DIM, but it might work for you. Let us know. If it doesn't work, then you're either going to have to find and fix whatever cygwin header defines DIM, or you're going to have to wait until we change that macro to LIBMESH_DIM (I'll probably find time to do so tomorrow afternoon or the following weekend) and then run the SVN libMesh version. --- Roy > 2008/5/30 John Peterson : > >> On Fri, May 30, 2008 at 11:56 AM, John Peterson >> wrote: >>> Hi, >>> >>> I haven't personally seen these errors before. I might take a look >>> into the autoconf documentation as is suggested and see if anything >>> promising pops up. >>> >>> As to your other problem, I don't see anything particularly sinister >>> about line 389 of the type_vector.h file (in the SVN head). I'll take >>> a look at the 0.6.2 version momentarily and see if anything else pops >>> out. >> >> OK, I take that back. >> >> In 0.6.2 that line is an error() which can only occur if the code has >> been compiled with DIM < 3. This is likely a bug on our part, because >> we rarely compile with DIM=2, which I assume you did? A quick fix >> might be to re-configure with DIM=3 and see if the seg-fault goes >> away. >> >> -J >> >> >>> >>> >>> >>> On Fri, May 30, 2008 at 11:42 AM, Dmitry Matison >> wrote: >>>> Hello! >>>> I'm using libmesh via cygwin and have a problem with configure >> procedure. >>>> Have someone handled with these errors? >>>> >>>> checking dlfcn.h usability... no >>>>> checking dlfcn.h presence... yes >>>>> configure: WARNING: dlfcn.h: present but cannot be compiled >>>>> configure: WARNING: dlfcn.h: check for missing prerequisite >> headers? >>>>> configure: WARNING: dlfcn.h: see the Autoconf documentation >>>>> configure: WARNING: dlfcn.h: section "Present But Cannot Be >> Compiled" >>>>> configure: WARNING: dlfcn.h: proceeding with the preprocessor's result >>>>> configure: WARNING: dlfcn.h: in the future, the compiler will take >>>>> precedence >>>>> configure: WARNING: ## ------------------------------------------ >> ## >>>>> configure: WARNING: ## Report this to the AC_PACKAGE_NAME lists. >> ## >>>>> configure: WARNING: ## ------------------------------------------ >> ## >>>>> checking for dlfcn.h... yes >>>>> >>>>> checking rpc/rpc.h usability... no >>>>> checking rpc/rpc.h presence... yes >>>>> configure: WARNING: rpc/rpc.h: present but cannot be compiled >>>>> configure: WARNING: rpc/rpc.h: check for missing prerequisite >> headers? >>>>> configure: WARNING: rpc/rpc.h: see the Autoconf documentation >>>>> configure: WARNING: rpc/rpc.h: section "Present But Cannot Be >> Compiled" >>>>> configure: WARNING: rpc/rpc.h: proceeding with the preprocessor's >> result >>>>> configure: WARNING: rpc/rpc.h: in the future, the compiler will take >>>>> precedence >>>>> configure: WARNING: ## ------------------------------------------ >> ## >>>>> configure: WARNING: ## Report this to the AC_PACKAGE_NAME lists. >> ## >>>>> configure: WARNING: ## ------------------------------------------ >> ## >>>>> checking for rpc/rpc.h... yes >>>>> checking for xdrstdio_create... no >>>> >>>> >>>> Another problem is that I can't run the examples because of these >> errors: >>>> >>>> \$ ./ex0-opt.exe >>>>> [0] >> /cygdrive/d/projects/vs/libmesh-0.6.2/include/numerics/type_vector.h, >>>>> line 389, compiled May 29 >>>>> 2008 at 18:30:27 >>>>> Aborted (core dumped) >>>> >>>> >>>> >>>> >>>>> \$ ./ex4-opt -d 1 -n 20 >>>>> Running ./ex4-opt -d 1 -n 20 >>>>> >>>>> Mesh Information: >>>>> mesh_dimension()=1 >>>>> spatial_dimension()=2 >>>>> n_nodes()=41 >>>>> n_elem()=20 >>>>> n_local_elem()=20 >>>>> n_active_elem()=20 >>>>> n_subdomains()=1 >>>>> n_processors()=1 >>>>> processor_id()=0 >>>>> >>>>> EquationSystems >>>>> n_systems()=1 >>>>> System "Poisson" >>>>> Type "LinearImplicit" >>>>> Variables="u" >>>>> Finite Element Types="LAGRANGE", "JACOBI_20_00" >>>>> Infinite Element Mapping="CARTESIAN" >>>>> Approximation Orders="SECOND", "THIRD" >>>>> n_dofs()=41 >>>>> n_local_dofs()=41 >>>>> n_constrained_dofs()=0 >>>>> n_vectors()=1 >>>>> >>>>> [0] >> /cygdrive/d/projects/vs/libmesh-0.6.2/include/numerics/type_vector.h, >>>>> line 389, compiled May 29 >>>>> 2008 at 18:30:27 >>>>> Aborted (core dumped) >>>>> >>>> >>>> >>>> \$ ./ex6-opt >>>>> Running ex6 with dim = 3 >>>>> >>>>> [0] >> /cygdrive/d/projects/vs/libmesh-0.6.2/include/numerics/type_vector.h, >>>>> line 389, compiled May 29 >>>>> 2008 at 18:25:18 >>>>> 11 [sig] ex6-opt 1088 >>>>> d:\projects\vs\libmesh-0.6.2\examples\ex6\ex6-opt.exe: *** fatal error >> - >>>>> called with threadlist_ix -1 >>>>> Hangup >>>> >>>> >>>> Regards, >>>> Matison Dmitry, >>>> student, Department of Applied Mathematics, >>>> Moscow Engineering Physics Institute (State University). >>>> >> ------------------------------------------------------------------------- >>>> 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/ >>>> _______________________________________________ >>>> Libmesh-users mailing list >>>> Libmesh-users@... >>>> https://lists.sourceforge.net/lists/listinfo/libmesh-users >>>> >>> >> > ------------------------------------------------------------------------- > 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/ > _______________________________________________ > Libmesh-users mailing list > Libmesh-users@... > https://lists.sourceforge.net/lists/listinfo/libmesh-users > ```

 Re: [Libmesh-users] rpc/rpc.h usability and other problems From: John Peterson - 2008-05-30 18:17 ```On Fri, May 30, 2008 at 12:33 PM, Roy Stogner wrote: > >> Sounds like a good plan, along the lines of your changes of error() -> >> libmesh_error(), etc. While we're at it, should we also consider >> similar changes for the other #defines in libmesh_config.h? For >> example, all the HAVE_LIBRARYFOO would become LIBMESH_HAVE_LIBRARYFOO, >> etc. Granted, these are less likely than DIM to trip over other >> libraries but as the library gets more mature I think this is a >> natural progression... > > Not a bad idea. We'd also stick some temporary lines like: > > #define HAVE_LIBRARYFOO LIBMESH_HAVE_LIBRARYFOO > > at the bottom of libmesh_config.h? Just something for 0.6.9 to be AFAIK, libmesh_config.h.in is auto-generated by autoconf/autoheader, and libmesh_config.h is auto-generated from it. I agree with you that we should try to keep things backwards-compatible though... One way to accomplish this might be to modify all the configure tests to define both HAVE_LIBRARYFOO and LIBMESH_HAVE_LIBRARYFOO simultaneously. In this case, though, I'd be worried about breaking configure tests... and it sounds like a lot of work. If you have any other ideas I'd be happy to hear them. Changing these #defines seems like a fairly straightforward task, though, and I'd like to take a crack at it. -J > removed in 0.7.0, like the current error() macro. I don't see any > good way to give a deprecated() type warning to applications that > still use the old macros, but we could at least give users a little > bit of forwards/backwards compatibility so that anyone using such > macros in their own code doesn't have to change application code at > the *exact* same time as they upgrade the library. > --- > Roy > ```

 Re: [Libmesh-users] rpc/rpc.h usability and other problems From: Roy Stogner - 2008-05-30 18:36 ```On Fri, 30 May 2008, John Peterson wrote: > AFAIK, libmesh_config.h.in is auto-generated by autoconf/autoheader, > and libmesh_config.h is auto-generated from it. Whoops - you're right. I remembered about the autoconf stuff, but forgot about autoheader. In fact, for the last couple new configure tests I added, I forgot to run autoheader and I just edited libmesh_config.h.in by hand! :-P > I agree with you that we should try to keep things > backwards-compatible though... > > One way to accomplish this might be to modify all the configure tests > to define both HAVE_LIBRARYFOO and LIBMESH_HAVE_LIBRARYFOO > simultaneously. In this case, though, I'd be worried about breaking > configure tests... and it sounds like a lot of work. Yeah, my autoconf skills also lean towards "touch configure.in as little as possible". We could add AC_DEFINE_UNQUOTED entries, I suppose; that would be straightforward enough. It looks like autoheader sorts things alphabetically, but that shouldn't be a problem, right? Whether "#define LIBMESH_FOO FOO" comes before or after "#define FOO BAR", it should still work. > If you have any other ideas I'd be happy to hear them. Changing > these #defines seems like a fairly straightforward task, though, and > I'd like to take a crack at it. Thanks; go for it! I wasn't sure I'd be able to get around to this tomorrow anyway, so I'll wait for you to take the first shot at the changes, and if there's any problems or if you can't find the time then I'll get to it in a week. --- Roy ```

 Re: [Libmesh-users] rpc/rpc.h usability and other problems From: Dmitry Matison - 2008-05-31 21:27 ```I've found that notation "--enable-2D-only=no" makes library to be configured with 2D-only option, because, after manual assignment of DIM in libmesh_common.h there was errors in compiling - redefining. So, now I've eliminated this line and the library works good finally. As to the rpc.h problem, I'm going to use ASCII variant - xda, because I have no ideas how to fix it, and think that this change will not effect productivity too much, main procedures take more time. Thank you for quick help! Regards, Dmitry. 2008/5/30 Roy Stogner : > > On Fri, 30 May 2008, Dmitry Matison wrote: > > Thanks for your help, Jonh and Roy! >> I've tried to configure with these options DIM=3 --enable-2D-only=no\, >> (was --enable-2D-only=no) >> but the errors remain. >> > > --enable-2D-only should be off by default; if you didn't turn it on > intentionally, then your code must be picking up a bad DIM somewhere > else. > > Let's see if we can just override it for now. > > In libmesh_common.h, there are the following lines: > > // 3D spatial dimension unless otherwise specified > #ifndef DIM > # define DIM 3 > #endif > > Replace them with this: > > // 3D spatial dimension unless otherwise specified > #undef DIM > #define DIM 3 > > > That's not likely to be a relible fix, since it depends on > libmesh_common.h being included *after* whatever cygwin header already > defined DIM, but it might work for you. Let us know. If it doesn't > work, then you're either going to have to find and fix whatever cygwin > header defines DIM, or you're going to have to wait until we change > that macro to LIBMESH_DIM (I'll probably find time to do so tomorrow > afternoon or the following weekend) and then run the SVN libMesh > version. > --- > Roy > > > 2008/5/30 John Peterson : >> >> On Fri, May 30, 2008 at 11:56 AM, John Peterson >>> wrote: >>> >>>> Hi, >>>> >>>> I haven't personally seen these errors before. I might take a look >>>> into the autoconf documentation as is suggested and see if anything >>>> promising pops up. >>>> >>>> As to your other problem, I don't see anything particularly sinister >>>> about line 389 of the type_vector.h file (in the SVN head). I'll take >>>> a look at the 0.6.2 version momentarily and see if anything else pops >>>> out. >>>> >>> >>> OK, I take that back. >>> >>> In 0.6.2 that line is an error() which can only occur if the code has >>> been compiled with DIM < 3. This is likely a bug on our part, because >>> we rarely compile with DIM=2, which I assume you did? A quick fix >>> might be to re-configure with DIM=3 and see if the seg-fault goes >>> away. >>> >>> -J >>> >>> >>> >>>> >>>> >>>> On Fri, May 30, 2008 at 11:42 AM, Dmitry Matison >>>> >>> wrote: >>> >>>> Hello! >>>>> I'm using libmesh via cygwin and have a problem with configure >>>>> >>>> procedure. >>> >>>> Have someone handled with these errors? >>>>> >>>>> checking dlfcn.h usability... no >>>>> >>>>>> checking dlfcn.h presence... yes >>>>>> configure: WARNING: dlfcn.h: present but cannot be compiled >>>>>> configure: WARNING: dlfcn.h: check for missing prerequisite >>>>>> >>>>> headers? >>> >>>> configure: WARNING: dlfcn.h: see the Autoconf documentation >>>>>> configure: WARNING: dlfcn.h: section "Present But Cannot Be >>>>>> >>>>> Compiled" >>> >>>> configure: WARNING: dlfcn.h: proceeding with the preprocessor's result >>>>>> configure: WARNING: dlfcn.h: in the future, the compiler will take >>>>>> precedence >>>>>> configure: WARNING: ## ------------------------------------------ >>>>>> >>>>> ## >>> >>>> configure: WARNING: ## Report this to the AC_PACKAGE_NAME lists. >>>>>> >>>>> ## >>> >>>> configure: WARNING: ## ------------------------------------------ >>>>>> >>>>> ## >>> >>>> checking for dlfcn.h... yes >>>>>> >>>>>> checking rpc/rpc.h usability... no >>>>>> checking rpc/rpc.h presence... yes >>>>>> configure: WARNING: rpc/rpc.h: present but cannot be compiled >>>>>> configure: WARNING: rpc/rpc.h: check for missing prerequisite >>>>>> >>>>> headers? >>> >>>> configure: WARNING: rpc/rpc.h: see the Autoconf documentation >>>>>> configure: WARNING: rpc/rpc.h: section "Present But Cannot Be >>>>>> >>>>> Compiled" >>> >>>> configure: WARNING: rpc/rpc.h: proceeding with the preprocessor's >>>>>> >>>>> result >>> >>>> configure: WARNING: rpc/rpc.h: in the future, the compiler will take >>>>>> precedence >>>>>> configure: WARNING: ## ------------------------------------------ >>>>>> >>>>> ## >>> >>>> configure: WARNING: ## Report this to the AC_PACKAGE_NAME lists. >>>>>> >>>>> ## >>> >>>> configure: WARNING: ## ------------------------------------------ >>>>>> >>>>> ## >>> >>>> checking for rpc/rpc.h... yes >>>>>> checking for xdrstdio_create... no >>>>>> >>>>> >>>>> >>>>> Another problem is that I can't run the examples because of these >>>>> >>>> errors: >>> >>>> >>>>> \$ ./ex0-opt.exe >>>>> >>>>>> [0] >>>>>> >>>>> /cygdrive/d/projects/vs/libmesh-0.6.2/include/numerics/type_vector.h, >>> >>>> line 389, compiled May 29 >>>>>> 2008 at 18:30:27 >>>>>> Aborted (core dumped) >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> \$ ./ex4-opt -d 1 -n 20 >>>>>> Running ./ex4-opt -d 1 -n 20 >>>>>> >>>>>> Mesh Information: >>>>>> mesh_dimension()=1 >>>>>> spatial_dimension()=2 >>>>>> n_nodes()=41 >>>>>> n_elem()=20 >>>>>> n_local_elem()=20 >>>>>> n_active_elem()=20 >>>>>> n_subdomains()=1 >>>>>> n_processors()=1 >>>>>> processor_id()=0 >>>>>> >>>>>> EquationSystems >>>>>> n_systems()=1 >>>>>> System "Poisson" >>>>>> Type "LinearImplicit" >>>>>> Variables="u" >>>>>> Finite Element Types="LAGRANGE", "JACOBI_20_00" >>>>>> Infinite Element Mapping="CARTESIAN" >>>>>> Approximation Orders="SECOND", "THIRD" >>>>>> n_dofs()=41 >>>>>> n_local_dofs()=41 >>>>>> n_constrained_dofs()=0 >>>>>> n_vectors()=1 >>>>>> >>>>>> [0] >>>>>> >>>>> /cygdrive/d/projects/vs/libmesh-0.6.2/include/numerics/type_vector.h, >>> >>>> line 389, compiled May 29 >>>>>> 2008 at 18:30:27 >>>>>> Aborted (core dumped) >>>>>> >>>>>> >>>>> >>>>> \$ ./ex6-opt >>>>> >>>>>> Running ex6 with dim = 3 >>>>>> >>>>>> [0] >>>>>> >>>>> /cygdrive/d/projects/vs/libmesh-0.6.2/include/numerics/type_vector.h, >>> >>>> line 389, compiled May 29 >>>>>> 2008 at 18:25:18 >>>>>> 11 [sig] ex6-opt 1088 >>>>>> d:\projects\vs\libmesh-0.6.2\examples\ex6\ex6-opt.exe: *** fatal error >>>>>> >>>>> - >>> >>>> called with threadlist_ix -1 >>>>>> Hangup >>>>>> >>>>> >>>>> >>>>> Regards, >>>>> Matison Dmitry, >>>>> student, Department of Applied Mathematics, >>>>> Moscow Engineering Physics Institute (State University). >>>>> >>>>> ------------------------------------------------------------------------- >>> >>>> 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/ >>>>> _______________________________________________ >>>>> Libmesh-users mailing list >>>>> Libmesh-users@... >>>>> https://lists.sourceforge.net/lists/listinfo/libmesh-users >>>>> >>>>> >>>> >>> ------------------------------------------------------------------------- >> 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/ >> _______________________________________________ >> Libmesh-users mailing list >> Libmesh-users@... >> https://lists.sourceforge.net/lists/listinfo/libmesh-users >> >> ```

 [Libmesh-users] Neumann condition implementation From: Maxime Debon - 2008-06-01 12:57 ```Hi, Trying to implement a Neumann condition at the upper boundary of a 1D transient problem, I am facing an interesting case. In fact, changing the size of the domain, modifying the value Xmax of the upper boundary, alters the result. //-------------------------------------------------------// for (unsigned int i=0; i 133.33 and to big when Xmax < 133.33. Using a second order Lagrange element, I may forget a correction term to evaluate the surface integral. Any ideas are welcome, Maxime ```

 Re: [Libmesh-users] Neumann condition implementation From: Roy Stogner - 2008-06-01 14:48 ```On Sun, 1 Jun 2008, Maxime Debon wrote: > Trying to implement a Neumann condition at the upper boundary of a 1D > transient problem, I am facing an interesting case. In fact, changing > the size of the domain, modifying the value Xmax of the upper > boundary, alters the result. > > //-------------------------------------------------------// > for (unsigned int i=0; i { > Number valueNeumann= 1.0; > Fe(i) += JxW_face[qp]*valueNeumann*phi_face[i][qp]; > } > //-------------------------------------------------------// > > To illustrate, the value of the first derivative at the boundary is > effectively 1.0 only when the value of Xmax is 133.3333. Elsewhere, > the derivative is too small when Xmax > 133.33 and to big when Xmax < > 133.33. > Using a second order Lagrange element, I may forget a correction term > to evaluate the surface integral. No correction term should be needed; libMesh should get phi_face right regardless of what element type you use. But my first question would be: are you sure the solution is sufficiently converged? Remember, Neumann conditions are only enforced weakly, so if you try to impose a boundary derivative of 1.0 this way, all you'll get is a formulation whose boundary derivative converges to 1.0 as your mesh size goes to zero. On coarser meshes, the finite element formulation can satisfy the boundary condition less accurately as part of an attempt to simultaneously satisfy the interior PDE more accurately. It's possible that your magic number of Xmax = 400/3 is just a fluke that gives you superconvergence at the boundary for your PDE and mesh. If I haven't correctly guessed what the problem is, could you boil it down to a short test case for us? --- Roy ```

 Re: [Libmesh-users] Neumann condition implementation From: Maxime Debon - 2008-06-04 10:53 ```Hi, First, thank you for your fast answer. After, multiple tries, I found that the number of timesteps has also an influence on the solution but not the number of elements nor the refinement's deep. I can't figure out the convergence mecanism with Neumann whereas it seems obvious with Dirichlet. Quoting Roy Stogner : > I can't tell for sure, but it looks like there may be a bit of conflict > between your time discretization and your Neumann boundary conditions? > Make sure you're really solving "du/dx|xmax = g", not "d^2 u/dxdt|xmax = g" You are right, the Neumann condition returns good results in static mode but not in transient. As I was using the theta method, I tried with the Newmark system (from ex. 8) to figure out a way to implement this Neumann boundary, but the problem still exists. Therefore, I replaced the Dirichlet condition in the dirichlet function by a Neumann condition. // ------------------------------------------------------ // if (fabs(curr_node(0)-Xmax) < TOLERANCE) { unsigned int dn = curr_node.dof_number(0,0,0); double neumann_value = 1.0; force.add(dn,neumann_value); } // ------------------------------------------------------ // Now, it seems that the derivative value at the upper side only depends on Xmax (not on dt). In that way, the good result is obtained with on approximative value of Xmax=55. Then, the same phenomenon occurs, if Xmax < 55, the upper derivative is > 1 and if Xmax > 55, the upper derivative is < 1. Another way to proceed would prefer the use of infinite elements but some restrictions have been made in 1D as it is explained in InfElemBuilder class : "00572 // 1D infinite elements not supported" So, the questions are : How to construct a free Neumann condition ? Is there any way to circumvent restrictions and use infinite elements in 1D ? Thanks a lot, Maxime ```

 Re: [Libmesh-users] Neumann condition implementation From: Roy Stogner - 2008-06-04 14:52 ```On Wed, 4 Jun 2008, Maxime Debon wrote: > Quoting Roy Stogner : >> I can't tell for sure, but it looks like there may be a bit of conflict >> between your time discretization and your Neumann boundary conditions? >> Make sure you're really solving "du/dx|xmax = g", not "d^2 u/dxdt|xmax = g" Looking over your code, since you're solving directly for u_n+1 rather than solving for delta_u_n and adding it to u_n, it looks like my guess here was wrong. > You are right, the Neumann condition returns good results in static mode but > not in transient. As I was using the theta method, I tried with the Newmark > system (from ex. 8) to figure out a way to implement this Neumann boundary, > but the problem still exists. Therefore, I replaced the Dirichlet condition > in the dirichlet function by a Neumann condition. > > > // ------------------------------------------------------ // > > if (fabs(curr_node(0)-Xmax) < TOLERANCE) > { > unsigned int dn = curr_node.dof_number(0,0,0); > double neumann_value = 1.0; > force.add(dn,neumann_value); > } This looks like it's just basically doing the same side "integration" that we normally do for Neumann conditions, just with lower level APIs. I can't see anything obviously wrong on second glance either, but if you can whittle this down to a system where libMesh gives results that differ from what you can calculate by hand, let us know. --- Roy ```