The problem in FIN-S has gone after checking out the latest version of libmesh from svn. I can now define the #include "exodusII_io.h" before the #ifdef LIBMESH_HAVE_PETSC. This is with petsc-3.1-p3 on a Mac OS X 10.6. Thanks for the fix. Rochan
On Thu, Aug 26, 2010 at 1:27 PM, <[email protected]> wrote: > Send Libmesh-users mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/libmesh-users > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Libmesh-users digest..." > > > Today's Topics: > > 1. Re: Periodic BC with adaptive mesh (Roy Stogner) > 2. Re: Periodic BC with adaptive mesh (Derek Gaston) > 3. Re: Periodic BC with adaptive mesh (Roy Stogner) > 4. variables values on xyz coordinates (Nestor M. Solalinde) > 5. Re: variables values on xyz coordinates (Roy Stogner) > 6. Re: problem in allgather (parallel.h)? (fwd) (Roy Stogner) > 7. Re: an anomaly in FINS (Ming Q) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 19 Aug 2010 13:02:45 -0500 (CDT) > From: Roy Stogner <[email protected]> > Subject: Re: [Libmesh-users] Periodic BC with adaptive mesh > To: Ming Q <[email protected]> > Cc: [email protected] > Message-ID: > <[email protected]> > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > On Thu, 19 Aug 2010, Ming Q wrote: > >> Here is the test case that will show the BC constrain is broken after the >> refinement. > > This replicates here perfectly; thanks. And cutting down the mesh > size to 2x2 (then expanding the refinement criteria to y>5 to > compensate) reduces the problem to something I can look at by hand. > I'm swamped lately but I'll try to check it out this weekend. > > Unless any other interested parties want to try to beat me to it? > E.g. I think Derek's coworkers already ran into this bug, but just > hadn't managed to boil it down to such a simple test case. > --- > Roy > > > > ------------------------------ > > Message: 2 > Date: Thu, 19 Aug 2010 12:05:41 -0600 > From: Derek Gaston <[email protected]> > Subject: Re: [Libmesh-users] Periodic BC with adaptive mesh > To: Roy Stogner <[email protected]> > Cc: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > Yes... we're seeing this too... but haven't had time to go further. There > are other modifications to the periodic constraints that are on my todo > list.... most notably the ability to apply them to individual variables > instead of EVERY variable in the system. Yes, I know it sounds weird, but we > really do have a system of equations where some variables are periodic and > others aren't... > > Unfortunately.... I _still_ don't have time immediately to look at either of > these issues.... > > Derek > > On Aug 19, 2010, at 12:02 PM, Roy Stogner wrote: > >> >> On Thu, 19 Aug 2010, Ming Q wrote: >> >>> Here is the test case that will show the BC constrain is broken after the >>> refinement. >> >> This replicates here perfectly; thanks. And cutting down the mesh >> size to 2x2 (then expanding the refinement criteria to y>5 to >> compensate) reduces the problem to something I can look at by hand. >> I'm swamped lately but I'll try to check it out this weekend. >> >> Unless any other interested parties want to try to beat me to it? >> E.g. I think Derek's coworkers already ran into this bug, but just >> hadn't managed to boil it down to such a simple test case. >> --- >> Roy >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by >> >> Make an app they can't live without >> Enter the BlackBerry Developer Challenge >> http://p.sf.net/sfu/RIM-dev2dev >> _______________________________________________ >> Libmesh-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/libmesh-users > > > > > ------------------------------ > > Message: 3 > Date: Sun, 22 Aug 2010 19:04:22 -0500 (CDT) > From: Roy Stogner <[email protected]> > Subject: Re: [Libmesh-users] Periodic BC with adaptive mesh > To: Ming Q <[email protected]> > Cc: [email protected] > Message-ID: > <[email protected]> > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > On Thu, 19 Aug 2010, Roy Stogner wrote: > >> This replicates here perfectly; thanks. And cutting down the mesh >> size to 2x2 (then expanding the refinement criteria to y>5 to >> compensate) reduces the problem to something I can look at by hand. >> I'm swamped lately but I'll try to check it out this weekend. > > I actually had time to look at the problem and I actually found a fix > pretty quickly. Give the svn HEAD a try. And don't take my > confidence as a replacement for verification. in particular, although > I think the fix should work in 3D and for multi-level constraint cases > I wouldn't trust it would testing. > > One more catch if you're using AMR with periodic BCs: I don't think > the JumpErrorEstimator or PatchRecoveryErrorEstimator classes are > currently PeriodicBoundary-aware. How suboptimal the resulting > refinement patterns are will depend on your application. > --- > Roy > > > > ------------------------------ > > Message: 4 > Date: Mon, 23 Aug 2010 19:34:15 -0300 > From: "Nestor M. Solalinde" <[email protected]> > Subject: [Libmesh-users] variables values on xyz coordinates > To: [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > Dear libmesh Developers: > > Is there a way to get the value of a certain variable on a specific xyz > coordinate?. For example: I could do this by using PointLocatorTree, get the > element and the values on the nodes and then using my own interpolating > function, but maybe this is not the best way. Any suggestions? > > Nestor Solalinde > > > ------------------------------ > > Message: 5 > Date: Mon, 23 Aug 2010 18:29:55 -0500 (CDT) > From: Roy Stogner <[email protected]> > Subject: Re: [Libmesh-users] variables values on xyz coordinates > To: "Nestor M. Solalinde" <[email protected]> > Cc: [email protected] > Message-ID: > <[email protected]> > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > On Mon, 23 Aug 2010, Nestor M. Solalinde wrote: > >> Is there a way to get the value of a certain variable on a specific xyz >> coordinate?. For example: I could do this by using PointLocatorTree, get the >> element and the values on the nodes and then using my own interpolating >> function, but maybe this is not the best way. Any suggestions? > > That is (for completely arbitrary xyz coordinates) the best way, and > it's encapsulated in MeshFunction. > --- > Roy > > > > ------------------------------ > > Message: 6 > Date: Wed, 25 Aug 2010 14:39:39 -0500 (CDT) > From: Roy Stogner <[email protected]> > Subject: Re: [Libmesh-users] problem in allgather (parallel.h)? (fwd) > To: [email protected], > [email protected] > Message-ID: > <[email protected]> > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > Copying this to the mailing lists in case someone else ever runs into > the same problems. > > Short version: before you use any other libMesh objects, you need to > construct a libMeshInit object. Perhaps some subsets of some versions > of the library under some runtime conditions let you get away without > it, but that's not worth trying to rely on. > --- > Roy > > ---------- Forwarded message ---------- > Date: Wed, 25 Aug 2010 14:55:25 -0400 > From: Sebastian Steiger <[email protected]> > To: Roy Stogner <[email protected]> > Subject: Re: problem in allgather (parallel.h)? > > Victory! > > Indeed the LibMeshInit object was constructed at a later stage (I didn't show > you the entire code). The code was written by somebody else and according to > that person he was able to use the integration methods even without calling > LibMeshInit. > > Moving LibMeshInit to the top of our code solved the problem. I apologize for > not spotting this earlier... it seems though as if that initialization is now > madatory and hasn't been before. > > I'm also not sure why that assert in the Mesh constructor was passed... > > Thank you for your support and sorry for taking away so much of your time > Sebastian > > > > On 08/25/2010 02:40 PM, Roy Stogner wrote: >> >> On Wed, 25 Aug 2010, Sebastian Steiger wrote: >> >>> I recompiled everything using METHOD=dbg. The problem looks the same. >>> When I check Communicator_World.size() it seems to be 0 right at the >>> start of the program already. >>> >>> BTW, my program testboost.cpp uses libmesh as a library: >> >> Except you don't seem to be creating a LibMeshInit object (or doing >> the deprecated equivalent, calling libMesh::init()). >> >> That would certainly explain why Communicator_World hadn't been >> initialized. I'm not sure how the program even got to print_info with >> METHOD=dbg on, though; the Mesh constructor should have failed at a >> libmesh_assert(libMesh::initialized()); test. >> --- >> Roy >> >>> int main() >>> { >>> msg.add_outstream(&std::cout); >>> >>> msg << "test 1D integration...\n"; >>> msg << "Communicator_World.size()=" << >>> Parallel::Communicator_World.size() << "\n"; >>> >>> Integrator integrator; >>> >>> Mesh mesh(1); >>> >>> MeshTools::Generation::build_line(mesh, 10, 0., 1.0, EDGE2); >>> >>> mesh.print_info(); >>> >>> integrator.set_mesh(&mesh); >>> integrator.set_order(2); >>> integrator.build_integral_sum(); >>> >>> const std::vector<std::vector<double> >& x = integrator.get_points(); >>> const std::vector<double> & w = integrator.get_weights(); >>> >>> double s = 0; >>> int n = x.size(); >>> >>> for (int i = 0; i < n; i++) >>> { >>> s += w[i] * f(x[i][0], x[i][1], x[i][2]); >>> } >>> >>> //BOOST_CHECK_CLOSE(s, 1.0/3.0, 1e-10); >>> cout << "Integral sum = " << s << "\n"; >>> return 0; >>> } >>> >>> >>> >>> >>> On 08/25/2010 02:06 PM, Roy Stogner wrote: >>>> >>>> On Wed, 25 Aug 2010, Sebastian Steiger wrote: >>>> >>>>> <ss parallel.h:1772> set_union. comm.size()=0, >>>>> Communicator_World.size()=0 >>>>> >>>>> i.e., Communicator_World also has size 0. What can I do against that? >>>> >>>> You don't happen to have an MPI stack that requires you to use mpirun >>>> or mpiexec even for 1-processor cases, do you? >>>> >>>> Are you running in debug mode? (you should be - there's a bug) If >>>> you are then your code made it past >>>> libmesh_assert (libMeshPrivateData::_n_processors > 0); >>>> in libMesh.C. It might be interesting to start polling >>>> Communicator_World after that point and see when it's size() changes >>>> and why. >>>> --- >>>> Roy >>> >>> > > > > > ------------------------------ > > Message: 7 > Date: Thu, 26 Aug 2010 20:27:35 +0200 > From: Ming Q <[email protected]> > Subject: Re: [Libmesh-users] an anomaly in FINS > To: Derek Gaston <[email protected]> > Cc: [email protected], Karl Schulz > <[email protected]>, rochan <[email protected]> > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > I also saw the same thing when I run the example 19. But this is gone when I > move back to use the petsc-3.0.0-p11. This petsc version did not defined the > variable PETSC_HAVE_XMMINTRIN_H then I can run the code ... > > / Ming Q > > On Aug 10, 2010, at 5:27 PM, Derek Gaston wrote: > >> Interesting... I'll get Cody to give this a try. We've never run into this >> though... and have tons of mac users using ExodusII. But of course that >> doesn't mean much if we just happen to have gotten lucky for all of this >> time. >> >> Derek >> >> On Aug 9, 2010, at 3:01 PM, Roy Stogner wrote: >> >>> >>> On Mon, 9 Aug 2010, rochan wrote: >>> >>>> I came across something that is inexplicable to me in the FINS code. >>> >>> Looks like this might be a more general libMesh-on-OSX issue, so I'm >>> going to Cc: to the libmesh-users mailing list. >>> >>>> When >>>> trying to add the option to write out in an Exodus Format in the physics.c >>>> code, I tried to insert the line #include "exodusII_io.h" below the line >>>> #include "vtk_io.h". The compiler complained with the following: >>>> >>>> In file included from >>>> /Users/rochanupadhyay/software_installs/gcc-4.5.0/lib/gcc/x86_64-apple-darwin10.3.0/4.5.0/include/xmmintrin.h:39:0, >>>> from >>>> /Users/rochanupadhyay/software_installs/petsc-3.1-p3/include/petscsys.h:1702, >>>> from >>>> /Users/rochanupadhyay/software_installs/petsc-3.1-p3/include/petscoptions.h:6, >>>> from physics.C:48: >>>> /Users/rochanupadhyay/software_installs/gcc-4.5.0/lib/gcc/x86_64-apple-darwin10.3.0/4.5.0/include/mm_malloc.h: >>>> In function 'void* _mm_malloc(size_t, size_t)': >>>> /Users/rochanupadhyay/software_installs/gcc-4.5.0/lib/gcc/x86_64-apple-darwin10.3.0/4.5.0/include/mm_malloc.h:39:7: >>>> error: '__error' was not declared in this scope >>>> make[3]: *** [physics.lo] Error 1 >>>> >>>> However when I put in the #include "exodusII_io.h" below the #ifdef >>>> LIBMESH_HAVE_PETSC ... block it builds fine and I can output ExodusII files >>>> and visualize it in Paraview. It is as if the compiler wants the "#ifdef >>>> LIBMESH_HAVE_PETSC ..." to appear at a particular line (line 48 in this >>>> case). And adding any lines pushes it down and it complains and does not >>>> build. I am not sure what effect I am observing here. It is useful to put >>>> the exodus_io header declaration with the other guys (vtk, gmv etc.) but >>>> don't know why the compiler is behaving in this way. >>> >>> Our own stuff in exodusII_io.h is pretty well made unique with the >>> libMesh namespace and LIBMESH_ prefix, but we also include the >>> third-party C header file exodusII.h, which defines a bunch of >>> preprocessor tokens with the possibly-non-unique prefix of EX_, and >>> which goes so far as to >>> #define TRUE -1 >>> >>> Yes, that's right: (true == TRUE) == false. (shaking head sadly) >>> >>> My guess is that one of those definitions is conflicting with some >>> internal definition in the Darwin headers. I can't replicate the >>> problem on Linux; I'm trying to replicate it on an (older) OSX system >>> now. >>> >>> It looks like we're only scarfing two constants from exodusII.h into >>> our own headers. We might be able to move them to extern variables, >>> then only include exodusII.h into the few library source files that >>> need it rather than into every user source file that wants to >>> read/write Exodus stuff. That won't fix any symbol conflicts (just >>> postpone them until linking) but it would at least fix any macro >>> conficts. If I can replicate the problem here I'll try to do that. >>> If I can't then hopefully your workaround will be sufficient until I >>> can borrow your laptop or something. >>> --- >>> Roy >>> >>> ------------------------------------------------------------------------------ >>> This SF.net email is sponsored by >>> >>> Make an app they can't live without >>> Enter the BlackBerry Developer Challenge >>> http://p.sf.net/sfu/RIM-dev2dev >>> _______________________________________________ >>> Libmesh-users mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/libmesh-users >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by >> >> Make an app they can't live without >> Enter the BlackBerry Developer Challenge >> http://p.sf.net/sfu/RIM-dev2dev >> _______________________________________________ >> Libmesh-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/libmesh-users > > > > > ------------------------------ > > ------------------------------------------------------------------------------ > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > Be part of this innovative community and reach millions of netbook users > worldwide. Take advantage of special opportunities to increase revenue and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d > > ------------------------------ > > _______________________________________________ > Libmesh-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/libmesh-users > > > End of Libmesh-users Digest, Vol 51, Issue 10 > ********************************************* > ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
