You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(2) |
Nov
(27) |
Dec
(31) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(6) |
Feb
(15) |
Mar
(33) |
Apr
(10) |
May
(46) |
Jun
(11) |
Jul
(21) |
Aug
(15) |
Sep
(13) |
Oct
(23) |
Nov
(1) |
Dec
(8) |
2005 |
Jan
(27) |
Feb
(57) |
Mar
(86) |
Apr
(23) |
May
(37) |
Jun
(34) |
Jul
(24) |
Aug
(17) |
Sep
(50) |
Oct
(24) |
Nov
(10) |
Dec
(60) |
2006 |
Jan
(47) |
Feb
(46) |
Mar
(127) |
Apr
(19) |
May
(26) |
Jun
(62) |
Jul
(47) |
Aug
(51) |
Sep
(61) |
Oct
(42) |
Nov
(50) |
Dec
(33) |
2007 |
Jan
(60) |
Feb
(55) |
Mar
(77) |
Apr
(102) |
May
(82) |
Jun
(102) |
Jul
(169) |
Aug
(117) |
Sep
(80) |
Oct
(37) |
Nov
(51) |
Dec
(43) |
2008 |
Jan
(71) |
Feb
(94) |
Mar
(98) |
Apr
(125) |
May
(54) |
Jun
(119) |
Jul
(60) |
Aug
(111) |
Sep
(118) |
Oct
(125) |
Nov
(119) |
Dec
(94) |
2009 |
Jan
(109) |
Feb
(38) |
Mar
(93) |
Apr
(88) |
May
(29) |
Jun
(57) |
Jul
(53) |
Aug
(48) |
Sep
(68) |
Oct
(151) |
Nov
(23) |
Dec
(35) |
2010 |
Jan
(84) |
Feb
(60) |
Mar
(184) |
Apr
(112) |
May
(60) |
Jun
(90) |
Jul
(23) |
Aug
(70) |
Sep
(119) |
Oct
(27) |
Nov
(47) |
Dec
(54) |
2011 |
Jan
(22) |
Feb
(19) |
Mar
(92) |
Apr
(93) |
May
(35) |
Jun
(91) |
Jul
(32) |
Aug
(61) |
Sep
(7) |
Oct
(69) |
Nov
(81) |
Dec
(23) |
2012 |
Jan
(64) |
Feb
(95) |
Mar
(35) |
Apr
(36) |
May
(63) |
Jun
(98) |
Jul
(70) |
Aug
(171) |
Sep
(149) |
Oct
(64) |
Nov
(67) |
Dec
(126) |
2013 |
Jan
(108) |
Feb
(104) |
Mar
(171) |
Apr
(133) |
May
(108) |
Jun
(100) |
Jul
(93) |
Aug
(126) |
Sep
(74) |
Oct
(59) |
Nov
(145) |
Dec
(93) |
2014 |
Jan
(38) |
Feb
(45) |
Mar
(26) |
Apr
(41) |
May
(125) |
Jun
(70) |
Jul
(61) |
Aug
(66) |
Sep
(60) |
Oct
(110) |
Nov
(27) |
Dec
(30) |
2015 |
Jan
(43) |
Feb
(67) |
Mar
(71) |
Apr
(92) |
May
(39) |
Jun
(15) |
Jul
(46) |
Aug
(63) |
Sep
(84) |
Oct
(82) |
Nov
(69) |
Dec
(45) |
2016 |
Jan
(92) |
Feb
(91) |
Mar
(148) |
Apr
(43) |
May
(58) |
Jun
(117) |
Jul
(92) |
Aug
(140) |
Sep
(49) |
Oct
(33) |
Nov
(85) |
Dec
(40) |
2017 |
Jan
(41) |
Feb
(36) |
Mar
(49) |
Apr
(41) |
May
(73) |
Jun
(51) |
Jul
(12) |
Aug
(69) |
Sep
(26) |
Oct
(43) |
Nov
(75) |
Dec
(23) |
2018 |
Jan
(86) |
Feb
(36) |
Mar
(50) |
Apr
(28) |
May
(53) |
Jun
(65) |
Jul
(26) |
Aug
(43) |
Sep
(32) |
Oct
(28) |
Nov
(52) |
Dec
(17) |
2019 |
Jan
(39) |
Feb
(26) |
Mar
(71) |
Apr
(30) |
May
(73) |
Jun
(18) |
Jul
(5) |
Aug
(10) |
Sep
(8) |
Oct
(24) |
Nov
(12) |
Dec
(34) |
2020 |
Jan
(17) |
Feb
(10) |
Mar
(6) |
Apr
(4) |
May
(15) |
Jun
(3) |
Jul
(8) |
Aug
(15) |
Sep
(6) |
Oct
(3) |
Nov
|
Dec
(4) |
2021 |
Jan
(4) |
Feb
(4) |
Mar
(21) |
Apr
(14) |
May
(13) |
Jun
(18) |
Jul
(1) |
Aug
(39) |
Sep
(1) |
Oct
|
Nov
(3) |
Dec
|
2022 |
Jan
|
Feb
|
Mar
(2) |
Apr
(8) |
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
(3) |
Nov
|
Dec
|
2023 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(7) |
Sep
(3) |
Oct
|
Nov
|
Dec
(1) |
From: Ted K. <ted...@go...> - 2009-07-28 23:20:10
|
Hi I realise that this is probably trivial to most of you but I'd appreciate it if you could help me out. My systems Ubuntu 9.04. Installed libmesh, petsc, etc from the repository. Tried to compile the examples and this is what I get: /usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib/libmesh.so: undefined reference to `MPI::Win::Set_errhandler(MPI::Errhandler const&)' /usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib/libmesh.so: undefined reference to `MPI::Comm::Set_errhandler(MPI::Errhandler const&)' collect2: ld returned 1 exit status I've tried compiling libmesh from source, I've also installed the latest openmpi build (1.3.3) but I still get the same result. I'd very much appreciate it if someone could point out how I can resolve this. Thanks Ted |
From: Geordie M. <gdm...@fr...> - 2009-07-28 21:28:35
|
On 7/28/09, Derek Gaston <fri...@gm...> wrote: > Looks like for now you have to check out the source... > http://sourceforge.net/scm/?type=cvs&group_id=211609 Ah yes, I see it now, thanks. |
From: Derek G. <fri...@gm...> - 2009-07-28 05:33:58
|
Looks like for now you have to check out the source... http://sourceforge.net/scm/?type=cvs&group_id=211609 (on a side note... I just used copy and paste on my iPhone for the first time... And it was everything I thought it would be ;-) Derek Sent from my iPhone On Jul 27, 2009, at 5:20 PM, Geordie McBain <gdm...@fr...> wrote: > On Tue, Jul 28, 2009 at 9:12 AM, Derek Gaston<fri...@gm...> > wrote: >> No... I still haven't fixed the writer so that it doesn't blow up >> when >> trying to write a block 0.... but I do have good Exodus related news: >> The full SEACAS set of tools has been open sourced: http://sourceforge.net/projects/seacas/ > > That sounds interesting, but there aren't any files at > http://sourceforge.net/projects/seacas/files. I couldn't see anything > to download. Where's the code? |
From: Geordie M. <gdm...@fr...> - 2009-07-27 23:20:16
|
On Tue, Jul 28, 2009 at 9:12 AM, Derek Gaston<fri...@gm...> wrote: > No... I still haven't fixed the writer so that it doesn't blow up when > trying to write a block 0.... but I do have good Exodus related news: > The full SEACAS set of tools has been open sourced: http://sourceforge.net/projects/seacas/ That sounds interesting, but there aren't any files at http://sourceforge.net/projects/seacas/files. I couldn't see anything to download. Where's the code? |
From: Derek G. <fri...@gm...> - 2009-07-27 23:12:35
|
No... I still haven't fixed the writer so that it doesn't blow up when trying to write a block 0.... but I do have good Exodus related news: The full SEACAS set of tools has been open sourced: http://sourceforge.net/projects/seacas/ This includes nem_slice and nem_spread which can take a serial ExodusII file and decompose it for parallel reading by a parallel Nemesis reader (which libMesh supports) and put parallel Nemesis files back together to create a serial Exodus file (for visualization, etc). Also... SEACAS includes exodiff... which can show you the difference between solutions stored in two different Exodus files. It somewhat overlaps with meshtool... but does have it's uses. For instance, we use it for regression tests because it can tell you when your solution changes within some tolerance (so that changing machines architectures or operating systems won't cause false positives). Anyway... if you use ExodusII i/o with libMesh you should probably check out SEACAS... it's a pretty useful set of tools. Derek |
From: Derek G. <fri...@gm...> - 2009-07-27 15:00:35
|
That's another hack that works... glad you found one ;-) If you are looking for a free visualizer that reads Exodus and handles Quad9... use Paraview: http://www.paraview.org Derek On Jul 27, 2009, at 8:03 AM, Boyce Griffith wrote: > Hi, Derek -- > > Thanks for the explanation --- I hacked the Exodus II I/O to > increment all block numbers by 1 and it seems to work. (Next > problem is that VisIt doesn't seem to be able to handle QUAD9 > elements, but that's a problem for another mailing list...) > > Thanks, > > -- Boyce > > Derek Gaston wrote: >> The issue is that Exodus blocks start numbering at 1 instead of >> zero.... You can loop over the elements and set their subdomain ID >> to one to fix that error... But unfortunately you will probably run >> into the next problem which is that Exodus boundary IDs start at 1 >> as well... >> The real fix is not to use the internal mesh generation of >> libmesh... And instead read an exodus mesh in (which will have >> boundary ids and block ids starting at 1). >> I have a hacked up version of libmesh's mesh generators that forces >> them to start at 1 for numbering... But its just that: a hack. It >> won't be commited. What I have on my list to do is to turn ids of >> 0 to MAX_ID when output... That way the examples will work. If I >> get a minute I'll try to do that today. >> Sorry about the trouble. >> Derek >> Sent from my iPhone >> On Jul 27, 2009, at 5:37 AM, Boyce Griffith <gri...@ci...> >> wrote: >>> Hi, Folks -- >>> >>> I am trying to get libMesh to output to an Exodus II file. I am >>> using a >>> recent pull of the SVN version of libMesh so that I can use >>> libMesh with >>> PETSc 3.0.0. >>> >>> (By the way, I don't really care whether it is Exodus II or not >>> --- I am >>> just trying to output data in a format which can be read by the >>> VisIt >>> visualization tool.) >>> >>> I tried modifying ex3.C to change the I/O from GMV to ExodusII, >>> i.e., I >>> simply changed the I/O from: >>> >>> // After solving the system write the solution >>> // to a GMV-formatted plot file. >>> GMVIO (mesh).write_equation_systems ("out.gmv", equation_systems); >>> >>> to: >>> >>> // After solving the system write the solution >>> // to a Exodus II-formatted plot file. >>> ExodusII_IO (mesh).write("out.exd"); >>> >>> This compiles fine but I get the following error at run time: >>> >>> [ex_put_block] Error: element block id 0 already exists in file id >>> 13 >>> exerrval = -1 >>> Error writing element block. >>> [0] src/mesh/exodusII_io_helper.C, line 118, compiled Jul 27 2009 at >>> 12:09:26 >>> terminate called after throwing an instance of 'libMesh::LogicError' >>> what(): Error in libMesh internal logic >>> [griffith-macbook-pro:62440] *** Process received signal *** >>> [griffith-macbook-pro:62440] Signal: Abort trap (6) >>> [griffith-macbook-pro:62440] Signal code: (0) >>> [griffith-macbook-pro:62440] [ 0] 2 libSystem.B.dylib >>> 0x912762bb _sigtramp + 43 >>> [griffith-macbook-pro:62440] [ 1] 3 ??? >>> 0xffffffff 0x0 + 4294967295 >>> [griffith-macbook-pro:62440] [ 2] 4 libSystem.B.dylib >>> 0x912ea23a raise + 26 >>> [griffith-macbook-pro:62440] [ 3] 5 libSystem.B.dylib >>> 0x912f6679 abort + 73 >>> [griffith-macbook-pro:62440] [ 4] 6 libstdc++.6.dylib >>> 0x035b26ef _ZN9__gnu_cxx27__verbose_terminate_handlerEv + 335 >>> [griffith-macbook-pro:62440] [ 5] 7 libstdc++.6.dylib >>> 0x035b02a9 _ZSt14set_unexpectedPFvvE + 41 >>> [griffith-macbook-pro:62440] [ 6] 8 libstdc++.6.dylib >>> 0x035b02ec _ZSt9terminatev + 28 >>> [griffith-macbook-pro:62440] [ 7] 9 libstdc++.6.dylib >>> 0x035b03eb __cxa_throw + 107 >>> [griffith-macbook-pro:62440] [ 8] 10 libmesh.dylib >>> 0x0204bb03 _ZN18ExodusII_IO_Helper9check_errEiSs + 693 >>> [griffith-macbook-pro:62440] [ 9] 11 libmesh.dylib >>> 0x02050b76 _ZN18ExodusII_IO_Helper14write_elementsERK8MeshBase + >>> 786 >>> [griffith-macbook-pro:62440] [10] 12 libmesh.dylib >>> 0x02048021 _ZN11ExodusII_IO5writeERKSs + 953 >>> [griffith-macbook-pro:62440] [11] 13 ex3-dbg >>> 0x00002e06 main + 1353 >>> [griffith-macbook-pro:62440] [12] 14 ex3-dbg >>> 0x0000275e start + 54 >>> [griffith-macbook-pro:62440] *** End of error message *** >>> >>> I get similar errors if I try to do similar things in ex4. >>> >>> What do I need to do to output to this format? >>> >>> Thanks, >>> >>> -- Boyce >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Libmesh-devel mailing list >>> Lib...@li... >>> https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: Boyce G. <gri...@ci...> - 2009-07-27 14:11:29
|
Hi, David -- Thanks for the suggestion. I've tried using the Tecplot I/O, but the VisIt Tecplot reader doesn't seem to like the ASCII Tecpot files generated by libMesh. VisIt produces an error like the following: There was an error opening out.dat: The record type '#' found in the file was unknown. ExodusII seems to be working after forcing the numbering of the blocks to start at 1 instead of 0, so I think I'll just stick with that for now. Thanks, -- Boyce David Knezevic wrote: > Also, Boyce, it looks like VisIt can read Tecplot data, so you could > probably just use libMesh's TecplotIO. > > - Dave > > > > Derek Gaston wrote: >> The issue is that Exodus blocks start numbering at 1 instead of >> zero.... You can loop over the elements and set their subdomain ID >> to one to fix that error... But unfortunately you will probably run >> into the next problem which is that Exodus boundary IDs start at 1 as >> well... >> >> The real fix is not to use the internal mesh generation of libmesh... >> And instead read an exodus mesh in (which will have boundary ids and >> block ids starting at 1). >> >> I have a hacked up version of libmesh's mesh generators that forces >> them to start at 1 for numbering... But its just that: a hack. It >> won't be commited. What I have on my list to do is to turn ids of 0 >> to MAX_ID when output... That way the examples will work. If I get a >> minute I'll try to do that today. >> >> Sorry about the trouble. >> >> Derek >> >> Sent from my iPhone >> >> On Jul 27, 2009, at 5:37 AM, Boyce Griffith <gri...@ci...> >> wrote: >> >> >>> Hi, Folks -- >>> >>> I am trying to get libMesh to output to an Exodus II file. I am >>> using a >>> recent pull of the SVN version of libMesh so that I can use libMesh >>> with >>> PETSc 3.0.0. >>> >>> (By the way, I don't really care whether it is Exodus II or not --- >>> I am >>> just trying to output data in a format which can be read by the VisIt >>> visualization tool.) >>> >>> I tried modifying ex3.C to change the I/O from GMV to ExodusII, i.e., I >>> simply changed the I/O from: >>> >>> // After solving the system write the solution >>> // to a GMV-formatted plot file. >>> GMVIO (mesh).write_equation_systems ("out.gmv", equation_systems); >>> >>> to: >>> >>> // After solving the system write the solution >>> // to a Exodus II-formatted plot file. >>> ExodusII_IO (mesh).write("out.exd"); >>> >>> This compiles fine but I get the following error at run time: >>> >>> [ex_put_block] Error: element block id 0 already exists in file id 13 >>> exerrval = -1 >>> Error writing element block. >>> [0] src/mesh/exodusII_io_helper.C, line 118, compiled Jul 27 2009 at >>> 12:09:26 >>> terminate called after throwing an instance of 'libMesh::LogicError' >>> what(): Error in libMesh internal logic >>> [griffith-macbook-pro:62440] *** Process received signal *** >>> [griffith-macbook-pro:62440] Signal: Abort trap (6) >>> [griffith-macbook-pro:62440] Signal code: (0) >>> [griffith-macbook-pro:62440] [ 0] 2 libSystem.B.dylib >>> 0x912762bb _sigtramp + 43 >>> [griffith-macbook-pro:62440] [ 1] 3 ??? >>> 0xffffffff 0x0 + 4294967295 >>> [griffith-macbook-pro:62440] [ 2] 4 libSystem.B.dylib >>> 0x912ea23a raise + 26 >>> [griffith-macbook-pro:62440] [ 3] 5 libSystem.B.dylib >>> 0x912f6679 abort + 73 >>> [griffith-macbook-pro:62440] [ 4] 6 libstdc++.6.dylib >>> 0x035b26ef _ZN9__gnu_cxx27__verbose_terminate_handlerEv + 335 >>> [griffith-macbook-pro:62440] [ 5] 7 libstdc++.6.dylib >>> 0x035b02a9 _ZSt14set_unexpectedPFvvE + 41 >>> [griffith-macbook-pro:62440] [ 6] 8 libstdc++.6.dylib >>> 0x035b02ec _ZSt9terminatev + 28 >>> [griffith-macbook-pro:62440] [ 7] 9 libstdc++.6.dylib >>> 0x035b03eb __cxa_throw + 107 >>> [griffith-macbook-pro:62440] [ 8] 10 libmesh.dylib >>> 0x0204bb03 _ZN18ExodusII_IO_Helper9check_errEiSs + 693 >>> [griffith-macbook-pro:62440] [ 9] 11 libmesh.dylib >>> 0x02050b76 _ZN18ExodusII_IO_Helper14write_elementsERK8MeshBase + 786 >>> [griffith-macbook-pro:62440] [10] 12 libmesh.dylib >>> 0x02048021 _ZN11ExodusII_IO5writeERKSs + 953 >>> [griffith-macbook-pro:62440] [11] 13 ex3-dbg >>> 0x00002e06 main + 1353 >>> [griffith-macbook-pro:62440] [12] 14 ex3-dbg >>> 0x0000275e start + 54 >>> [griffith-macbook-pro:62440] *** End of error message *** >>> >>> I get similar errors if I try to do similar things in ex4. >>> >>> What do I need to do to output to this format? >>> >>> Thanks, >>> >>> -- Boyce >>> >>> --- --- --- >>> --------------------------------------------------------------------- >>> _______________________________________________ >>> Libmesh-devel mailing list >>> Lib...@li... >>> https://lists.sourceforge.net/lists/listinfo/libmesh-devel >>> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Libmesh-devel mailing list >> Lib...@li... >> https://lists.sourceforge.net/lists/listinfo/libmesh-devel >> > |
From: Boyce G. <gri...@ci...> - 2009-07-27 14:04:04
|
Hi, Derek -- Thanks for the explanation --- I hacked the Exodus II I/O to increment all block numbers by 1 and it seems to work. (Next problem is that VisIt doesn't seem to be able to handle QUAD9 elements, but that's a problem for another mailing list...) Thanks, -- Boyce Derek Gaston wrote: > The issue is that Exodus blocks start numbering at 1 instead of > zero.... You can loop over the elements and set their subdomain ID to > one to fix that error... But unfortunately you will probably run into > the next problem which is that Exodus boundary IDs start at 1 as well... > > The real fix is not to use the internal mesh generation of libmesh... > And instead read an exodus mesh in (which will have boundary ids and > block ids starting at 1). > > I have a hacked up version of libmesh's mesh generators that forces them > to start at 1 for numbering... But its just that: a hack. It won't be > commited. What I have on my list to do is to turn ids of 0 to MAX_ID > when output... That way the examples will work. If I get a minute I'll > try to do that today. > > Sorry about the trouble. > > Derek > > Sent from my iPhone > > On Jul 27, 2009, at 5:37 AM, Boyce Griffith <gri...@ci...> wrote: > >> Hi, Folks -- >> >> I am trying to get libMesh to output to an Exodus II file. I am using a >> recent pull of the SVN version of libMesh so that I can use libMesh with >> PETSc 3.0.0. >> >> (By the way, I don't really care whether it is Exodus II or not --- I am >> just trying to output data in a format which can be read by the VisIt >> visualization tool.) >> >> I tried modifying ex3.C to change the I/O from GMV to ExodusII, i.e., I >> simply changed the I/O from: >> >> // After solving the system write the solution >> // to a GMV-formatted plot file. >> GMVIO (mesh).write_equation_systems ("out.gmv", equation_systems); >> >> to: >> >> // After solving the system write the solution >> // to a Exodus II-formatted plot file. >> ExodusII_IO (mesh).write("out.exd"); >> >> This compiles fine but I get the following error at run time: >> >> [ex_put_block] Error: element block id 0 already exists in file id 13 >> exerrval = -1 >> Error writing element block. >> [0] src/mesh/exodusII_io_helper.C, line 118, compiled Jul 27 2009 at >> 12:09:26 >> terminate called after throwing an instance of 'libMesh::LogicError' >> what(): Error in libMesh internal logic >> [griffith-macbook-pro:62440] *** Process received signal *** >> [griffith-macbook-pro:62440] Signal: Abort trap (6) >> [griffith-macbook-pro:62440] Signal code: (0) >> [griffith-macbook-pro:62440] [ 0] 2 libSystem.B.dylib >> 0x912762bb _sigtramp + 43 >> [griffith-macbook-pro:62440] [ 1] 3 ??? >> 0xffffffff 0x0 + 4294967295 >> [griffith-macbook-pro:62440] [ 2] 4 libSystem.B.dylib >> 0x912ea23a raise + 26 >> [griffith-macbook-pro:62440] [ 3] 5 libSystem.B.dylib >> 0x912f6679 abort + 73 >> [griffith-macbook-pro:62440] [ 4] 6 libstdc++.6.dylib >> 0x035b26ef _ZN9__gnu_cxx27__verbose_terminate_handlerEv + 335 >> [griffith-macbook-pro:62440] [ 5] 7 libstdc++.6.dylib >> 0x035b02a9 _ZSt14set_unexpectedPFvvE + 41 >> [griffith-macbook-pro:62440] [ 6] 8 libstdc++.6.dylib >> 0x035b02ec _ZSt9terminatev + 28 >> [griffith-macbook-pro:62440] [ 7] 9 libstdc++.6.dylib >> 0x035b03eb __cxa_throw + 107 >> [griffith-macbook-pro:62440] [ 8] 10 libmesh.dylib >> 0x0204bb03 _ZN18ExodusII_IO_Helper9check_errEiSs + 693 >> [griffith-macbook-pro:62440] [ 9] 11 libmesh.dylib >> 0x02050b76 _ZN18ExodusII_IO_Helper14write_elementsERK8MeshBase + 786 >> [griffith-macbook-pro:62440] [10] 12 libmesh.dylib >> 0x02048021 _ZN11ExodusII_IO5writeERKSs + 953 >> [griffith-macbook-pro:62440] [11] 13 ex3-dbg >> 0x00002e06 main + 1353 >> [griffith-macbook-pro:62440] [12] 14 ex3-dbg >> 0x0000275e start + 54 >> [griffith-macbook-pro:62440] *** End of error message *** >> >> I get similar errors if I try to do similar things in ex4. >> >> What do I need to do to output to this format? >> >> Thanks, >> >> -- Boyce >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Libmesh-devel mailing list >> Lib...@li... >> https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: David K. <dknez@MIT.EDU> - 2009-07-27 13:43:07
|
Also, Boyce, it looks like VisIt can read Tecplot data, so you could probably just use libMesh's TecplotIO. - Dave Derek Gaston wrote: > The issue is that Exodus blocks start numbering at 1 instead of > zero.... You can loop over the elements and set their subdomain ID to > one to fix that error... But unfortunately you will probably run into > the next problem which is that Exodus boundary IDs start at 1 as well... > > The real fix is not to use the internal mesh generation of libmesh... > And instead read an exodus mesh in (which will have boundary ids and > block ids starting at 1). > > I have a hacked up version of libmesh's mesh generators that forces > them to start at 1 for numbering... But its just that: a hack. It > won't be commited. What I have on my list to do is to turn ids of 0 > to MAX_ID when output... That way the examples will work. If I get a > minute I'll try to do that today. > > Sorry about the trouble. > > Derek > > Sent from my iPhone > > On Jul 27, 2009, at 5:37 AM, Boyce Griffith <gri...@ci...> > wrote: > > >> Hi, Folks -- >> >> I am trying to get libMesh to output to an Exodus II file. I am >> using a >> recent pull of the SVN version of libMesh so that I can use libMesh >> with >> PETSc 3.0.0. >> >> (By the way, I don't really care whether it is Exodus II or not --- >> I am >> just trying to output data in a format which can be read by the VisIt >> visualization tool.) >> >> I tried modifying ex3.C to change the I/O from GMV to ExodusII, >> i.e., I >> simply changed the I/O from: >> >> // After solving the system write the solution >> // to a GMV-formatted plot file. >> GMVIO (mesh).write_equation_systems ("out.gmv", equation_systems); >> >> to: >> >> // After solving the system write the solution >> // to a Exodus II-formatted plot file. >> ExodusII_IO (mesh).write("out.exd"); >> >> This compiles fine but I get the following error at run time: >> >> [ex_put_block] Error: element block id 0 already exists in file id 13 >> exerrval = -1 >> Error writing element block. >> [0] src/mesh/exodusII_io_helper.C, line 118, compiled Jul 27 2009 at >> 12:09:26 >> terminate called after throwing an instance of 'libMesh::LogicError' >> what(): Error in libMesh internal logic >> [griffith-macbook-pro:62440] *** Process received signal *** >> [griffith-macbook-pro:62440] Signal: Abort trap (6) >> [griffith-macbook-pro:62440] Signal code: (0) >> [griffith-macbook-pro:62440] [ 0] 2 libSystem.B.dylib >> 0x912762bb _sigtramp + 43 >> [griffith-macbook-pro:62440] [ 1] 3 ??? >> 0xffffffff 0x0 + 4294967295 >> [griffith-macbook-pro:62440] [ 2] 4 libSystem.B.dylib >> 0x912ea23a raise + 26 >> [griffith-macbook-pro:62440] [ 3] 5 libSystem.B.dylib >> 0x912f6679 abort + 73 >> [griffith-macbook-pro:62440] [ 4] 6 libstdc++.6.dylib >> 0x035b26ef _ZN9__gnu_cxx27__verbose_terminate_handlerEv + 335 >> [griffith-macbook-pro:62440] [ 5] 7 libstdc++.6.dylib >> 0x035b02a9 _ZSt14set_unexpectedPFvvE + 41 >> [griffith-macbook-pro:62440] [ 6] 8 libstdc++.6.dylib >> 0x035b02ec _ZSt9terminatev + 28 >> [griffith-macbook-pro:62440] [ 7] 9 libstdc++.6.dylib >> 0x035b03eb __cxa_throw + 107 >> [griffith-macbook-pro:62440] [ 8] 10 libmesh.dylib >> 0x0204bb03 _ZN18ExodusII_IO_Helper9check_errEiSs + 693 >> [griffith-macbook-pro:62440] [ 9] 11 libmesh.dylib >> 0x02050b76 _ZN18ExodusII_IO_Helper14write_elementsERK8MeshBase + 786 >> [griffith-macbook-pro:62440] [10] 12 libmesh.dylib >> 0x02048021 _ZN11ExodusII_IO5writeERKSs + 953 >> [griffith-macbook-pro:62440] [11] 13 ex3-dbg >> 0x00002e06 main + 1353 >> [griffith-macbook-pro:62440] [12] 14 ex3-dbg >> 0x0000275e start + 54 >> [griffith-macbook-pro:62440] *** End of error message *** >> >> I get similar errors if I try to do similar things in ex4. >> >> What do I need to do to output to this format? >> >> Thanks, >> >> -- Boyce >> >> --- >> --- >> --- >> --------------------------------------------------------------------- >> _______________________________________________ >> Libmesh-devel mailing list >> Lib...@li... >> https://lists.sourceforge.net/lists/listinfo/libmesh-devel >> > > ------------------------------------------------------------------------------ > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel > |
From: Derek G. <fri...@gm...> - 2009-07-27 13:39:17
|
The issue is that Exodus blocks start numbering at 1 instead of zero.... You can loop over the elements and set their subdomain ID to one to fix that error... But unfortunately you will probably run into the next problem which is that Exodus boundary IDs start at 1 as well... The real fix is not to use the internal mesh generation of libmesh... And instead read an exodus mesh in (which will have boundary ids and block ids starting at 1). I have a hacked up version of libmesh's mesh generators that forces them to start at 1 for numbering... But its just that: a hack. It won't be commited. What I have on my list to do is to turn ids of 0 to MAX_ID when output... That way the examples will work. If I get a minute I'll try to do that today. Sorry about the trouble. Derek Sent from my iPhone On Jul 27, 2009, at 5:37 AM, Boyce Griffith <gri...@ci...> wrote: > Hi, Folks -- > > I am trying to get libMesh to output to an Exodus II file. I am > using a > recent pull of the SVN version of libMesh so that I can use libMesh > with > PETSc 3.0.0. > > (By the way, I don't really care whether it is Exodus II or not --- > I am > just trying to output data in a format which can be read by the VisIt > visualization tool.) > > I tried modifying ex3.C to change the I/O from GMV to ExodusII, > i.e., I > simply changed the I/O from: > > // After solving the system write the solution > // to a GMV-formatted plot file. > GMVIO (mesh).write_equation_systems ("out.gmv", equation_systems); > > to: > > // After solving the system write the solution > // to a Exodus II-formatted plot file. > ExodusII_IO (mesh).write("out.exd"); > > This compiles fine but I get the following error at run time: > > [ex_put_block] Error: element block id 0 already exists in file id 13 > exerrval = -1 > Error writing element block. > [0] src/mesh/exodusII_io_helper.C, line 118, compiled Jul 27 2009 at > 12:09:26 > terminate called after throwing an instance of 'libMesh::LogicError' > what(): Error in libMesh internal logic > [griffith-macbook-pro:62440] *** Process received signal *** > [griffith-macbook-pro:62440] Signal: Abort trap (6) > [griffith-macbook-pro:62440] Signal code: (0) > [griffith-macbook-pro:62440] [ 0] 2 libSystem.B.dylib > 0x912762bb _sigtramp + 43 > [griffith-macbook-pro:62440] [ 1] 3 ??? > 0xffffffff 0x0 + 4294967295 > [griffith-macbook-pro:62440] [ 2] 4 libSystem.B.dylib > 0x912ea23a raise + 26 > [griffith-macbook-pro:62440] [ 3] 5 libSystem.B.dylib > 0x912f6679 abort + 73 > [griffith-macbook-pro:62440] [ 4] 6 libstdc++.6.dylib > 0x035b26ef _ZN9__gnu_cxx27__verbose_terminate_handlerEv + 335 > [griffith-macbook-pro:62440] [ 5] 7 libstdc++.6.dylib > 0x035b02a9 _ZSt14set_unexpectedPFvvE + 41 > [griffith-macbook-pro:62440] [ 6] 8 libstdc++.6.dylib > 0x035b02ec _ZSt9terminatev + 28 > [griffith-macbook-pro:62440] [ 7] 9 libstdc++.6.dylib > 0x035b03eb __cxa_throw + 107 > [griffith-macbook-pro:62440] [ 8] 10 libmesh.dylib > 0x0204bb03 _ZN18ExodusII_IO_Helper9check_errEiSs + 693 > [griffith-macbook-pro:62440] [ 9] 11 libmesh.dylib > 0x02050b76 _ZN18ExodusII_IO_Helper14write_elementsERK8MeshBase + 786 > [griffith-macbook-pro:62440] [10] 12 libmesh.dylib > 0x02048021 _ZN11ExodusII_IO5writeERKSs + 953 > [griffith-macbook-pro:62440] [11] 13 ex3-dbg > 0x00002e06 main + 1353 > [griffith-macbook-pro:62440] [12] 14 ex3-dbg > 0x0000275e start + 54 > [griffith-macbook-pro:62440] *** End of error message *** > > I get similar errors if I try to do similar things in ex4. > > What do I need to do to output to this format? > > Thanks, > > -- Boyce > > --- > --- > --- > --------------------------------------------------------------------- > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: Boyce G. <gri...@ci...> - 2009-07-27 11:59:04
|
Hi, Folks -- I am trying to get libMesh to output to an Exodus II file. I am using a recent pull of the SVN version of libMesh so that I can use libMesh with PETSc 3.0.0. (By the way, I don't really care whether it is Exodus II or not --- I am just trying to output data in a format which can be read by the VisIt visualization tool.) I tried modifying ex3.C to change the I/O from GMV to ExodusII, i.e., I simply changed the I/O from: // After solving the system write the solution // to a GMV-formatted plot file. GMVIO (mesh).write_equation_systems ("out.gmv", equation_systems); to: // After solving the system write the solution // to a Exodus II-formatted plot file. ExodusII_IO (mesh).write("out.exd"); This compiles fine but I get the following error at run time: [ex_put_block] Error: element block id 0 already exists in file id 13 exerrval = -1 Error writing element block. [0] src/mesh/exodusII_io_helper.C, line 118, compiled Jul 27 2009 at 12:09:26 terminate called after throwing an instance of 'libMesh::LogicError' what(): Error in libMesh internal logic [griffith-macbook-pro:62440] *** Process received signal *** [griffith-macbook-pro:62440] Signal: Abort trap (6) [griffith-macbook-pro:62440] Signal code: (0) [griffith-macbook-pro:62440] [ 0] 2 libSystem.B.dylib 0x912762bb _sigtramp + 43 [griffith-macbook-pro:62440] [ 1] 3 ??? 0xffffffff 0x0 + 4294967295 [griffith-macbook-pro:62440] [ 2] 4 libSystem.B.dylib 0x912ea23a raise + 26 [griffith-macbook-pro:62440] [ 3] 5 libSystem.B.dylib 0x912f6679 abort + 73 [griffith-macbook-pro:62440] [ 4] 6 libstdc++.6.dylib 0x035b26ef _ZN9__gnu_cxx27__verbose_terminate_handlerEv + 335 [griffith-macbook-pro:62440] [ 5] 7 libstdc++.6.dylib 0x035b02a9 _ZSt14set_unexpectedPFvvE + 41 [griffith-macbook-pro:62440] [ 6] 8 libstdc++.6.dylib 0x035b02ec _ZSt9terminatev + 28 [griffith-macbook-pro:62440] [ 7] 9 libstdc++.6.dylib 0x035b03eb __cxa_throw + 107 [griffith-macbook-pro:62440] [ 8] 10 libmesh.dylib 0x0204bb03 _ZN18ExodusII_IO_Helper9check_errEiSs + 693 [griffith-macbook-pro:62440] [ 9] 11 libmesh.dylib 0x02050b76 _ZN18ExodusII_IO_Helper14write_elementsERK8MeshBase + 786 [griffith-macbook-pro:62440] [10] 12 libmesh.dylib 0x02048021 _ZN11ExodusII_IO5writeERKSs + 953 [griffith-macbook-pro:62440] [11] 13 ex3-dbg 0x00002e06 main + 1353 [griffith-macbook-pro:62440] [12] 14 ex3-dbg 0x0000275e start + 54 [griffith-macbook-pro:62440] *** End of error message *** I get similar errors if I try to do similar things in ex4. What do I need to do to output to this format? Thanks, -- Boyce |
From: Ted K. <ted...@go...> - 2009-07-24 00:10:06
|
Hi I just tried to compile Example 0 but with no success. I get the following error: /usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib/libmesh.so: undefined reference to `MPI::Win::Set_errhandler(MPI::Errhandler const&)' /usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib/libmesh.so: undefined reference to `MPI::Comm::Set_errhandler(MPI::Errhandler const&)' collect2: ld returned 1 exit status Can anyone help? Thanks in advance. Ted P.S: I'm linking with -llmesh an -lmpi |
From: Roy S. <roy...@ic...> - 2009-07-22 22:51:28
|
On Wed, 22 Jul 2009, Roy Stogner wrote: > Also, we've got some verified sensitivity results with > FEMSystem::qoi_parameter_sensitivity (a method which should probably > work with LinearImplicitSystem or NonlinearImplicitSystem as well, > but just hasn't been tested on them yet). Ugh. Make that "verified sensitivity results on a special case problem which apparently have a serious bug in the more general case". Apparently rushed, hubris-filled announcements of success are a bad idea... > Use at your own risk. I have nothing to add to this but it apparently deserved repeating. --- Roy |
From: Roy S. <roy...@ic...> - 2009-07-22 22:09:19
|
On Wed, 22 Jul 2009, Nachiket Gokhale wrote: > It would be nice to have a wrapper around libmesh to do > (distributed) parameter estimation based on adjoint sensitivities. Yes, but (until we start looking into extremely intrusive methods) we can still work well with any black-box package that supports a sensitivity-providing interface. I'm trying to talk the DAKOTA people into expanding some of their (already impressive) capabilities in that regard, and we're starting to add sensitivity-based UQ into the QUESO package at UTexas. > Libmesh probably already supports different grids for all variables > ( the material parameters, the solution, and the adjoint field), Not as much as we'd like. We're going to do some tricks to support adjoints on refined discretizations (similarly to how UniformRefinementEstimator results work now), and we can have differing discretization orders for different variables (e.g. a piecewise-constant material parameter used in a piecewise-quadratic approximation) easily enough. But using completely independent meshes would take either some serious library changes or a multi-mesh aware application code. > so it would be an interesting exercise to do a fully adaptive > parameter estimation. The trouble here is that you'd really want to be adaptive in parameter space, and we can't do that (for more than 3 parameters) with a libMesh mesh. I blame John and Ben's laziness, and I'd like to reassure everyone that we've got support for unstructured hyperhex meshes slated for libMesh 7.5. --- Roy |
From: Roy S. <roy...@ic...> - 2009-07-22 18:30:55
|
On Wed, 22 Jul 2009, David Knezevic wrote: > I added a "first order" SCALAR variable to a system with periodic BCs > and after I removed the libmesh_error()'s in fe_scalar_shape_*D.C, the > periodic SCALAR runs fine, and appears to work as we'd like (i.e. we'd > like the periodic constraint not to affect the SCALAR dof, since it's > automatically periodic). However, I just wanted to check if you think > there are any potential "gotcha's" with this? I don't think so. The code as it is will probably try to solve for constraint equations and detect that you have an "A = A" constraint, but when it sees those it just ignores them. (libMesh isn't an Ayn Rand fan?) You might be able to save unnecessary computation by specializing compute_periodic_constraints() to be a do-nothing function (and compute_constraints() as well while you're at it) or you might be able to get nearly the same improvement more simply by changing get_continuity() from C_ZERO to DISCONTINUOUS. --- Roy |
From: David K. <dknez@MIT.EDU> - 2009-07-22 18:22:02
|
Roy, I've got a quick question: I added a "first order" SCALAR variable to a system with periodic BCs and after I removed the libmesh_error()'s in fe_scalar_shape_*D.C, the periodic SCALAR runs fine, and appears to work as we'd like (i.e. we'd like the periodic constraint not to affect the SCALAR dof, since it's automatically periodic). However, I just wanted to check if you think there are any potential "gotcha's" with this? Thanks, Dave |
From: Roy S. <roy...@ic...> - 2009-07-22 16:44:31
|
On Wed, 22 Jul 2009, Roy Stogner wrote: > Also, we've got some verified sensitivity results with > FEMSystem::qoi_parameter_sensitivity This should say "adjoint-based sensitivity results" - the calculation type you'd want if you have a few quantities of interest but lots of parameters. We'll probably eventually rename that method to qoi_adjoint_parameter_sensitivities(). If you have lots of quantities of interest but few parameters, you'll want to use System::qoi_forward_parameter_sensitivities() instead, by which I mean you'll want to first add the declaration and implementations of a qoi_forward_parameter_sensitivities() method, then post a patch to libmesh-devel when you're done. ;-) --- Roy |
From: Roy S. <roy...@ic...> - 2009-07-22 16:31:49
|
For anyone interested in playing around with bleeding-edge libMesh features, the newest feature has reached a slightly-less-unstable state: We're now getting some decent goal-oriented refinement (for benchmark problems with moderately high amounts of convection, at least) with the AdjointResidualErrorEstimator (using a default PatchRecovery subestimator to keep things physics independent and keep the adjoint solve on the same mesh). Also, we've got some verified sensitivity results with FEMSystem::qoi_parameter_sensitivity (a method which should probably work with LinearImplicitSystem or NonlinearImplicitSystem as well, but just hasn't been tested on them yet). If your application code can produce an exact Jacobian, and if you care more about scalar quantities of interest than about Hilbert norms of the whole solution, then you might want to check out the SVN head. There's still bugs to fix (at least one subtle problem if you try to combine the AdjointResidual estimator with UniformRefinement subestimators, for instance), APIs that will change (we'll need a DiffContext::element_qoi to enable seamless FEMSystem multithreading, and we may break System::qoi in other ways to make handling multiple qois less awkward), and features that need to be added (using a refined adjoint solution as a weight, for instance, rather than being limited to error estimates of same-mesh adjoints). Use at your own risk. --- Roy |
From: David K. <dknez@MIT.EDU> - 2009-07-21 17:58:48
|
Hi Roy, > Which formulation are you using? If it's velocity-pressure, then > "make u, v, and w periodic" should be straightforward enough, but > you'll have to do something more complex with p, and right now the > DofMap APIs don't support anything more complex than "make every > variable periodic". Yeah, I'm using velocity-pressure. My boss suggested that we work with periodic pressure for this problem, so the default behavior of making all variables periodic is just what I needed for now... > I say "should be straightforward enough" because "is straightforward > enough" would apparently be inaccurate. You shouldn't have to call > create_dof_constraints() manually, it should be done automatically in > init() as long as you add the periodic boundary first, which is what > it sounds like you were doing originally. Glad you've found a > workaround, but I'm still not sure why it didn't work as expected in > the first place. heh actually, "is straightforward enough" is accurate... moving the "add_periodic_boundary" stuff above equation_systems.init() works fine also (and doesn't require the manual call to create_dof_constraints)... I had apparently tried moving the add_periodic_boundary call everywhere I could, except for above init... ugh. Thanks for the quick response. - Dave |
From: Roy S. <roy...@ic...> - 2009-07-21 17:42:32
|
On Tue, 21 Jul 2009, David Knezevic wrote: > I'm trying to do a Navier-Stokes channel flow problem with periodic BCs > on the left and right boundaries; Which formulation are you using? If it's velocity-pressure, then "make u, v, and w periodic" should be straightforward enough, but you'll have to do something more complex with p, and right now the DofMap APIs don't support anything more complex than "make every variable periodic". I say "should be straightforward enough" because "is straightforward enough" would apparently be inaccurate. You shouldn't have to call create_dof_constraints() manually, it should be done automatically in init() as long as you add the periodic boundary first, which is what it sounds like you were doing originally. Glad you've found a workaround, but I'm still not sure why it didn't work as expected in the first place. --- Roy |
From: David K. <dknez@MIT.EDU> - 2009-07-21 17:37:22
|
hah, it's always the way isn't it: you figure it out just after emailing the list... I moved the adding of the periodic BC to after equation_systems.init() and added the aptly named function call: dof_map.create_dof_constraints(mesh); and now it works! Cheers, Dave David Knezevic wrote: > Hi all, > > I'm trying to use libMesh's functionality for periodic boundary > conditions, but I can't quite figure it out... I looked it up in the > archives, but couldn't find any info. > > I'm trying to do a Navier-Stokes channel flow problem with periodic > BCs on the left and right boundaries; I added: > > PeriodicBoundary pbc; > pbc.myboundary = inflow_ID; > pbc.pairedboundary = outflow_ID; > > RealVectorValue boundary_translation(channel_length,0.,0.); > pbc.translation_vector = boundary_translation; > > dof_map.add_periodic_boundary(pbc); > > > to the matrix assembly (before the element loop), and then (as usual) > I called > > dof_map.constrain_element_matrix_and_vector (Ke, Fe, dof_indices); > > in order to impose the periodic constraint on the element matrices? I > guess I must be missing something, because this isn't giving me > periodicity? > > Thanks! > > Dave > |
From: David K. <dknez@MIT.EDU> - 2009-07-21 17:20:18
|
Hi all, I'm trying to use libMesh's functionality for periodic boundary conditions, but I can't quite figure it out... I looked it up in the archives, but couldn't find any info. I'm trying to do a Navier-Stokes channel flow problem with periodic BCs on the left and right boundaries; I added: PeriodicBoundary pbc; pbc.myboundary = inflow_ID; pbc.pairedboundary = outflow_ID; RealVectorValue boundary_translation(channel_length,0.,0.); pbc.translation_vector = boundary_translation; dof_map.add_periodic_boundary(pbc); to the matrix assembly (before the element loop), and then (as usual) I called dof_map.constrain_element_matrix_and_vector (Ke, Fe, dof_indices); in order to impose the periodic constraint on the element matrices? I guess I must be missing something, because this isn't giving me periodicity? Thanks! Dave |
From: John P. <pet...@cf...> - 2009-07-17 10:23:52
|
On Wed, Jul 15, 2009 at 7:17 PM, <ale...@ut...> wrote: > The jacobian for a 2d triangular element is a constant. I heard that for a > quadratic 2d triangular element the jacobian should be linear but I'm > getting a quadratic one (I'm using classical coordinate transformations: x = > ax' + by' + cx'y' + dx'^2 + ey'^2). It should be the same in natural > coordinates. Should the final result be linear? The 2D Jacobian is a 2x2 matrix given by [dx/dxi, dx/deta] [dy/dxi, dy/deta] Expressing x (resp y.) in terms of the quadratic basis functions phi: x = \sum_i x_i \phi_i and differentiating, you should be able to convince yourself that the entries of the Jacobian for the quadratic triangular element are linear in xi and eta, the coordinates of the reference element. Give it a try, the basis functions for the TRI6 can be found in src/fe/fe_lagrange_shape_2D.C starting at line 158. -- John |
From: Roy S. <roy...@ic...> - 2009-07-14 21:52:28
|
On Tue, 14 Jul 2009, Tim Campbell wrote: > FYI. In examples/ex20/ex20.C the macro LIBMESH_ENABLE_PETSC should be > changed to LIBMESH_HAVE_PETSC. Whoops! Thanks! --- Roy |
From: Tim C. <tim...@nr...> - 2009-07-14 21:42:20
|
FYI. In examples/ex20/ex20.C the macro LIBMESH_ENABLE_PETSC should be changed to LIBMESH_HAVE_PETSC. |