Menu
▾
▴
libmesh-users — General information for libmesh users
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: Bailey C. <bcu...@gm...> - 2018-08-07 13:08:06
|
Hi there, I'm using libMesh to calculate the homogenized properties of microstructures with cuboid unit cells. To do this, the boundaries of the unit cell require periodic boundary conditions. As far as I can tell, though, the PeriodicBoundary class only works with structured meshes, which isn't really a feasible option for me. Is this really the case, or have I just missed something in my implementation? Currently, I am manually mapping each constrained node on the "far" boundary to an element/side pair on the "near" boundary using PointLocatorBase and Elem::side_ptr()->contains_point(). Then, I use the penalty method to apply a constraint equation with coefficients found using FE<2,LAGRANGE>::shape(). The issue I have at the moment most likely concerns preallocation of the system matrix. Calls to matrix->add_matrix() are taking a very long time, since the DofMap would obviously not expect a node on one side of the mesh to be coupled with the nodes on the opposite side. Is there a convenient way to make libMesh preallocate extra space beforehand, or does this need to be done manually? I'm using PETSc, but I'd like the code to stay solver-independent if possible. I've considered switching to the Lagrange multiplier method using 2 additional field variables as was suggested for a question I posted earlier for a different project. However, this would add 2 DOFs to each node, and I'm not even sure this would circumvent the preallocation problem I have for the penalty method. Any suggestions concerning the best way to use libMesh for this problem would be appreciated. - Bailey C |
|
From: Barna B. <bar...@gm...> - 2018-08-06 16:03:22
|
Hello, I have a problem, where I need to solve a linear system in a transient simulation. However, the system I solve has no transient character, i.e. in each time step I just need to solve a new system. Anyway, at some point of my simulation, it seems like the result of my linear system becomes NaNs. I then wanted to check why this could be the case by using methods such as LinearImplicitSystem::n_linear_iterations() and LinearImplicitSystem::final_linear_residual() after having called the LinearImplicitSystem::solve() method. However, the two functions return 1 and 0 consistently. It seems to me that something does not get set properly, or perhaps I am missing something. Also calling LinearSolver::get_converged_reason() gives me a segfault. I would have liked to get some info as to why the solve “fails”/why I get back NaNs. Thank you for your help. Barna <https://www.youtube.com/channel/UCQiVLRF9ub-T8sW-RKIULMA> |
|
From: Roy S. <roy...@ic...> - 2018-08-02 04:33:42
|
Would someone copy that broken config.log to my email? Looks like the attachment got stripped by the mailing list. --- Roy On Wed, 1 Aug 2018, Harry Pearce wrote: > Paul, > Here it is! There is another problem but I think I know what's causing it > so I will ask if I can't figure it out. > > Thanks again, > Harrison Pearce > SDSU undergraduate in Chemical Physics > > On Wed, Aug 1, 2018 at 3:10 PM, Paul T. Bauman <ptb...@gm...> wrote: > >> >> >> On Wed, Aug 1, 2018 at 5:50 PM Harry Pearce <har...@gm...> >> wrote: >> >>> Paul, >>> Thanks! Your recommendation worked! >>> >> >> Great, glad you got it working. Let us know if you run into other issues. >> >> >>> My config.log file is attached just in case you still want to see it. >>> >> >> Thanks, but this is the one for your successful build. If you're willing, >> could you please pass along the for failed configure (when you didn't have >> --disable-metaphysicl)? Thanks! >> >> >>> >>> Thankfully, >>> Harrison Rojak Pearce >>> SDSU Undergraduate in Chemical Physics >>> >>> On Wed, Aug 1, 2018 at 1:34 PM, Paul T. Bauman <ptb...@gm...> >>> wrote: >>> >>>> Thanks for the report. >>>> >>>> If you don't need metaphysicl, probably the quickest thing you can do is >>>> pass `--disable-metaphysicl` >>>> to libmesh configure. >>>> >>>> What compiler are you using? I wonder if it's too old to build that >>>> boost module? >>>> Could you send along your config.log (can send to me directly, the >>>> mailing list will strip it). >>>> I'm curious to see what caused that failure. >>>> >>>> On Wed, Aug 1, 2018 at 4:17 PM Harry Pearce <har...@gm...> >>>> wrote: >>>> >>>>> Hello fellow libmesh users!, >>>>> >>>>> I am trying to configure libmesh 1.3.0. >>>>> When I run ./configure I get the error: >>>>> checking for Boost headers version >= 1.47.0... yes >>>>> checking for Boost's header version... 1_55 >>>>> checking for the toolset name used by Boost for mpicxx... configure: >>>>> WARNING: could not figure out which toolset name to use for mpicxx >>>>> >>>>> checking for the flags needed to use pthreads... conftest.cpp: In >>>>> function >>>>> 'int main()': >>>>> conftest.cpp:33:24: warning: null argument where non-null required >>>>> (argument 1) [-Wnonnull] >>>>> pthread_attr_init(0); pthread_cleanup_push(0, 0); >>>>> ^ >>>>> conftest.cpp:34:27: warning: null argument where non-null required >>>>> (argument 1) [-Wnonnull] >>>>> pthread_create(0,0,0,0); pthread_cleanup_pop(0); >>>>> ^ >>>>> conftest.cpp:34:27: warning: null argument where non-null required >>>>> (argument 3) [-Wnonnull] >>>>> conftest.cpp:32:34: warning: 'th' is used uninitialized in this function >>>>> [-Wuninitialized] >>>>> pthread_t th; pthread_join(th, 0); >>>>> ^ >>>>> -pthread >>>>> configure: /vexcl/vexcl.hpp not found >>>>> configure: /include/vexcl/vexcl.hpp not found >>>>> checking whether we are using the Microsoft C++ compiler... no >>>>> checking CL/cl.h usability... no >>>>> checking CL/cl.h presence... no >>>>> checking for CL/cl.h... no >>>>> checking OpenCL/cl.h usability... no >>>>> checking OpenCL/cl.h presence... no >>>>> checking for OpenCL/cl.h... no >>>>> checking windows.h usability... no >>>>> checking windows.h presence... no >>>>> checking for windows.h... no >>>>> checking for OpenCL library... no >>>>> checking boost/system/error_code.hpp usability... yes >>>>> checking boost/system/error_code.hpp presence... yes >>>>> checking for boost/system/error_code.hpp... yes >>>>> checking for the Boost system library... yes >>>>> checking boost/chrono.hpp usability... yes >>>>> checking boost/chrono.hpp presence... yes >>>>> checking for boost/chrono.hpp... yes >>>>> checking for the Boost chrono library... (cached) yes >>>>> checking boost/date_time/posix_time/posix_time.hpp usability... no >>>>> checking boost/date_time/posix_time/posix_time.hpp presence... yes >>>>> configure: WARNING: boost/date_time/posix_time/posix_time.hpp: present >>>>> but >>>>> cannot be compiled >>>>> configure: WARNING: boost/date_time/posix_time/posix_time.hpp: >>>>> check >>>>> for missing prerequisite headers? >>>>> configure: WARNING: boost/date_time/posix_time/posix_time.hpp: see the >>>>> Autoconf documentation >>>>> configure: WARNING: boost/date_time/posix_time/posix_time.hpp: >>>>> section >>>>> "Present But Cannot Be Compiled" >>>>> configure: WARNING: boost/date_time/posix_time/posix_time.hpp: >>>>> proceeding >>>>> with the compiler's result >>>>> configure: WARNING: ## --------------------------------------- ## >>>>> configure: WARNING: ## Report this to roy...@ic... ## >>>>> configure: WARNING: ## --------------------------------------- ## >>>>> checking for boost/date_time/posix_time/posix_time.hpp... no >>>>> configure: error: cannot find boost/date_time/posix_time/posix_time.hpp >>>>> configure: error: ./configure failed for contrib/metaphysicl/0.2.0 >>>>> >>>>> I thought the problem may have had to do with the installation of mpich >>>>> but I reinstalled it and the problem persists. I am wondering if the >>>>> problem is with libmesh, boost, or something else. >>>>> >>>>> I have read over some of the entries relating to this problem, and they >>>>> did >>>>> not help, although there are alot of entries so if someone has already >>>>> solved this problem and you can point me in the direction of their post, >>>>> that also works. >>>>> >>>>> Thanks, >>>>> Harrison Rojak Pearce >>>>> SDSU undergraduate in Chemical Physics >>>>> ------------------------------------------------------------ >>>>> ------------------ >>>>> Check out the vibrant tech community on one of the world's most >>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>>> _______________________________________________ >>>>> Libmesh-users mailing list >>>>> Lib...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/libmesh-users >>>>> >>>> >>> > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Libmesh-users mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-users > > |
|
From: Paul T. B. <ptb...@gm...> - 2018-08-02 01:36:33
|
It looks like you haven't set PETSC_DIR and PETSC_ARCH. You need to set these variables in your environment - these are how libMesh detects your PETSc installation. Similarly for SLEPc (although I believe SLEPc is just bundled with recent versions of PETSc, but don't quote me.) On Wed, Aug 1, 2018 at 7:11 PM Harry Pearce <har...@gm...> wrote: > Paul, > I fixed what I thought was causing a problem, but this didn't work. When I > use ./configure --disable-metaphysicl --with-petsc --with-slepc libmesh > becomes configured, but without petsc or slepc. I originally thought the > problem was the .bashrc file, which defined the PATH for the petsc and > slepc directories, but I fixed the bashrc file and this error still > persists. A new config.log file is attached. > > Harrison Pearce > SDSU Undergraduate in Chemical Physics > > On Wed, Aug 1, 2018 at 3:28 PM, Harry Pearce <har...@gm...> > wrote: > >> Paul, >> Here it is! There is another problem but I think I know what's causing it >> so I will ask if I can't figure it out. >> >> Thanks again, >> Harrison Pearce >> SDSU undergraduate in Chemical Physics >> >> On Wed, Aug 1, 2018 at 3:10 PM, Paul T. Bauman <ptb...@gm...> >> wrote: >> >>> >>> >>> On Wed, Aug 1, 2018 at 5:50 PM Harry Pearce <har...@gm...> >>> wrote: >>> >>>> Paul, >>>> Thanks! Your recommendation worked! >>>> >>> >>> Great, glad you got it working. Let us know if you run into other issues. >>> >>> >>>> My config.log file is attached just in case you still want to see it. >>>> >>> >>> Thanks, but this is the one for your successful build. If you're >>> willing, could you please pass along the for failed configure (when you >>> didn't have --disable-metaphysicl)? Thanks! >>> >>> >>>> >>>> Thankfully, >>>> Harrison Rojak Pearce >>>> SDSU Undergraduate in Chemical Physics >>>> >>>> On Wed, Aug 1, 2018 at 1:34 PM, Paul T. Bauman <ptb...@gm...> >>>> wrote: >>>> >>>>> Thanks for the report. >>>>> >>>>> If you don't need metaphysicl, probably the quickest thing you can do >>>>> is pass `--disable-metaphysicl` >>>>> to libmesh configure. >>>>> >>>>> What compiler are you using? I wonder if it's too old to build that >>>>> boost module? >>>>> Could you send along your config.log (can send to me directly, the >>>>> mailing list will strip it). >>>>> I'm curious to see what caused that failure. >>>>> >>>>> On Wed, Aug 1, 2018 at 4:17 PM Harry Pearce <har...@gm...> >>>>> wrote: >>>>> >>>>>> Hello fellow libmesh users!, >>>>>> >>>>>> I am trying to configure libmesh 1.3.0. >>>>>> When I run ./configure I get the error: >>>>>> checking for Boost headers version >= 1.47.0... yes >>>>>> checking for Boost's header version... 1_55 >>>>>> checking for the toolset name used by Boost for mpicxx... configure: >>>>>> WARNING: could not figure out which toolset name to use for mpicxx >>>>>> >>>>>> checking for the flags needed to use pthreads... conftest.cpp: In >>>>>> function >>>>>> 'int main()': >>>>>> conftest.cpp:33:24: warning: null argument where non-null required >>>>>> (argument 1) [-Wnonnull] >>>>>> pthread_attr_init(0); pthread_cleanup_push(0, 0); >>>>>> ^ >>>>>> conftest.cpp:34:27: warning: null argument where non-null required >>>>>> (argument 1) [-Wnonnull] >>>>>> pthread_create(0,0,0,0); pthread_cleanup_pop(0); >>>>>> ^ >>>>>> conftest.cpp:34:27: warning: null argument where non-null required >>>>>> (argument 3) [-Wnonnull] >>>>>> conftest.cpp:32:34: warning: 'th' is used uninitialized in this >>>>>> function >>>>>> [-Wuninitialized] >>>>>> pthread_t th; pthread_join(th, 0); >>>>>> ^ >>>>>> -pthread >>>>>> configure: /vexcl/vexcl.hpp not found >>>>>> configure: /include/vexcl/vexcl.hpp not found >>>>>> checking whether we are using the Microsoft C++ compiler... no >>>>>> checking CL/cl.h usability... no >>>>>> checking CL/cl.h presence... no >>>>>> checking for CL/cl.h... no >>>>>> checking OpenCL/cl.h usability... no >>>>>> checking OpenCL/cl.h presence... no >>>>>> checking for OpenCL/cl.h... no >>>>>> checking windows.h usability... no >>>>>> checking windows.h presence... no >>>>>> checking for windows.h... no >>>>>> checking for OpenCL library... no >>>>>> checking boost/system/error_code.hpp usability... yes >>>>>> checking boost/system/error_code.hpp presence... yes >>>>>> checking for boost/system/error_code.hpp... yes >>>>>> checking for the Boost system library... yes >>>>>> checking boost/chrono.hpp usability... yes >>>>>> checking boost/chrono.hpp presence... yes >>>>>> checking for boost/chrono.hpp... yes >>>>>> checking for the Boost chrono library... (cached) yes >>>>>> checking boost/date_time/posix_time/posix_time.hpp usability... no >>>>>> checking boost/date_time/posix_time/posix_time.hpp presence... yes >>>>>> configure: WARNING: boost/date_time/posix_time/posix_time.hpp: >>>>>> present but >>>>>> cannot be compiled >>>>>> configure: WARNING: boost/date_time/posix_time/posix_time.hpp: >>>>>> check >>>>>> for missing prerequisite headers? >>>>>> configure: WARNING: boost/date_time/posix_time/posix_time.hpp: see the >>>>>> Autoconf documentation >>>>>> configure: WARNING: boost/date_time/posix_time/posix_time.hpp: >>>>>> section >>>>>> "Present But Cannot Be Compiled" >>>>>> configure: WARNING: boost/date_time/posix_time/posix_time.hpp: >>>>>> proceeding >>>>>> with the compiler's result >>>>>> configure: WARNING: ## --------------------------------------- ## >>>>>> configure: WARNING: ## Report this to roy...@ic... ## >>>>>> configure: WARNING: ## --------------------------------------- ## >>>>>> checking for boost/date_time/posix_time/posix_time.hpp... no >>>>>> configure: error: cannot find >>>>>> boost/date_time/posix_time/posix_time.hpp >>>>>> configure: error: ./configure failed for contrib/metaphysicl/0.2.0 >>>>>> >>>>>> I thought the problem may have had to do with the installation of >>>>>> mpich >>>>>> but I reinstalled it and the problem persists. I am wondering if the >>>>>> problem is with libmesh, boost, or something else. >>>>>> >>>>>> I have read over some of the entries relating to this problem, and >>>>>> they did >>>>>> not help, although there are alot of entries so if someone has already >>>>>> solved this problem and you can point me in the direction of their >>>>>> post, >>>>>> that also works. >>>>>> >>>>>> Thanks, >>>>>> Harrison Rojak Pearce >>>>>> SDSU undergraduate in Chemical Physics >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> Check out the vibrant tech community on one of the world's most >>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>>>> _______________________________________________ >>>>>> Libmesh-users mailing list >>>>>> Lib...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/libmesh-users >>>>>> >>>>> >>>> >> > |
|
From: Harry P. <har...@gm...> - 2018-08-01 23:11:40
|
Paul, I fixed what I thought was causing a problem, but this didn't work. When I use ./configure --disable-metaphysicl --with-petsc --with-slepc libmesh becomes configured, but without petsc or slepc. I originally thought the problem was the .bashrc file, which defined the PATH for the petsc and slepc directories, but I fixed the bashrc file and this error still persists. A new config.log file is attached. Harrison Pearce SDSU Undergraduate in Chemical Physics On Wed, Aug 1, 2018 at 3:28 PM, Harry Pearce <har...@gm...> wrote: > Paul, > Here it is! There is another problem but I think I know what's causing it > so I will ask if I can't figure it out. > > Thanks again, > Harrison Pearce > SDSU undergraduate in Chemical Physics > > On Wed, Aug 1, 2018 at 3:10 PM, Paul T. Bauman <ptb...@gm...> wrote: > >> >> >> On Wed, Aug 1, 2018 at 5:50 PM Harry Pearce <har...@gm...> >> wrote: >> >>> Paul, >>> Thanks! Your recommendation worked! >>> >> >> Great, glad you got it working. Let us know if you run into other issues. >> >> >>> My config.log file is attached just in case you still want to see it. >>> >> >> Thanks, but this is the one for your successful build. If you're willing, >> could you please pass along the for failed configure (when you didn't have >> --disable-metaphysicl)? Thanks! >> >> >>> >>> Thankfully, >>> Harrison Rojak Pearce >>> SDSU Undergraduate in Chemical Physics >>> >>> On Wed, Aug 1, 2018 at 1:34 PM, Paul T. Bauman <ptb...@gm...> >>> wrote: >>> >>>> Thanks for the report. >>>> >>>> If you don't need metaphysicl, probably the quickest thing you can do >>>> is pass `--disable-metaphysicl` >>>> to libmesh configure. >>>> >>>> What compiler are you using? I wonder if it's too old to build that >>>> boost module? >>>> Could you send along your config.log (can send to me directly, the >>>> mailing list will strip it). >>>> I'm curious to see what caused that failure. >>>> >>>> On Wed, Aug 1, 2018 at 4:17 PM Harry Pearce <har...@gm...> >>>> wrote: >>>> >>>>> Hello fellow libmesh users!, >>>>> >>>>> I am trying to configure libmesh 1.3.0. >>>>> When I run ./configure I get the error: >>>>> checking for Boost headers version >= 1.47.0... yes >>>>> checking for Boost's header version... 1_55 >>>>> checking for the toolset name used by Boost for mpicxx... configure: >>>>> WARNING: could not figure out which toolset name to use for mpicxx >>>>> >>>>> checking for the flags needed to use pthreads... conftest.cpp: In >>>>> function >>>>> 'int main()': >>>>> conftest.cpp:33:24: warning: null argument where non-null required >>>>> (argument 1) [-Wnonnull] >>>>> pthread_attr_init(0); pthread_cleanup_push(0, 0); >>>>> ^ >>>>> conftest.cpp:34:27: warning: null argument where non-null required >>>>> (argument 1) [-Wnonnull] >>>>> pthread_create(0,0,0,0); pthread_cleanup_pop(0); >>>>> ^ >>>>> conftest.cpp:34:27: warning: null argument where non-null required >>>>> (argument 3) [-Wnonnull] >>>>> conftest.cpp:32:34: warning: 'th' is used uninitialized in this >>>>> function >>>>> [-Wuninitialized] >>>>> pthread_t th; pthread_join(th, 0); >>>>> ^ >>>>> -pthread >>>>> configure: /vexcl/vexcl.hpp not found >>>>> configure: /include/vexcl/vexcl.hpp not found >>>>> checking whether we are using the Microsoft C++ compiler... no >>>>> checking CL/cl.h usability... no >>>>> checking CL/cl.h presence... no >>>>> checking for CL/cl.h... no >>>>> checking OpenCL/cl.h usability... no >>>>> checking OpenCL/cl.h presence... no >>>>> checking for OpenCL/cl.h... no >>>>> checking windows.h usability... no >>>>> checking windows.h presence... no >>>>> checking for windows.h... no >>>>> checking for OpenCL library... no >>>>> checking boost/system/error_code.hpp usability... yes >>>>> checking boost/system/error_code.hpp presence... yes >>>>> checking for boost/system/error_code.hpp... yes >>>>> checking for the Boost system library... yes >>>>> checking boost/chrono.hpp usability... yes >>>>> checking boost/chrono.hpp presence... yes >>>>> checking for boost/chrono.hpp... yes >>>>> checking for the Boost chrono library... (cached) yes >>>>> checking boost/date_time/posix_time/posix_time.hpp usability... no >>>>> checking boost/date_time/posix_time/posix_time.hpp presence... yes >>>>> configure: WARNING: boost/date_time/posix_time/posix_time.hpp: >>>>> present but >>>>> cannot be compiled >>>>> configure: WARNING: boost/date_time/posix_time/posix_time.hpp: >>>>> check >>>>> for missing prerequisite headers? >>>>> configure: WARNING: boost/date_time/posix_time/posix_time.hpp: see the >>>>> Autoconf documentation >>>>> configure: WARNING: boost/date_time/posix_time/posix_time.hpp: >>>>> section >>>>> "Present But Cannot Be Compiled" >>>>> configure: WARNING: boost/date_time/posix_time/posix_time.hpp: >>>>> proceeding >>>>> with the compiler's result >>>>> configure: WARNING: ## --------------------------------------- ## >>>>> configure: WARNING: ## Report this to roy...@ic... ## >>>>> configure: WARNING: ## --------------------------------------- ## >>>>> checking for boost/date_time/posix_time/posix_time.hpp... no >>>>> configure: error: cannot find boost/date_time/posix_time/pos >>>>> ix_time.hpp >>>>> configure: error: ./configure failed for contrib/metaphysicl/0.2.0 >>>>> >>>>> I thought the problem may have had to do with the installation of >>>>> mpich >>>>> but I reinstalled it and the problem persists. I am wondering if the >>>>> problem is with libmesh, boost, or something else. >>>>> >>>>> I have read over some of the entries relating to this problem, and >>>>> they did >>>>> not help, although there are alot of entries so if someone has already >>>>> solved this problem and you can point me in the direction of their >>>>> post, >>>>> that also works. >>>>> >>>>> Thanks, >>>>> Harrison Rojak Pearce >>>>> SDSU undergraduate in Chemical Physics >>>>> ------------------------------------------------------------ >>>>> ------------------ >>>>> Check out the vibrant tech community on one of the world's most >>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>>> _______________________________________________ >>>>> Libmesh-users mailing list >>>>> Lib...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/libmesh-users >>>>> >>>> >>> > |
|
From: Harry P. <har...@gm...> - 2018-08-01 22:28:39
|
Paul, Here it is! There is another problem but I think I know what's causing it so I will ask if I can't figure it out. Thanks again, Harrison Pearce SDSU undergraduate in Chemical Physics On Wed, Aug 1, 2018 at 3:10 PM, Paul T. Bauman <ptb...@gm...> wrote: > > > On Wed, Aug 1, 2018 at 5:50 PM Harry Pearce <har...@gm...> > wrote: > >> Paul, >> Thanks! Your recommendation worked! >> > > Great, glad you got it working. Let us know if you run into other issues. > > >> My config.log file is attached just in case you still want to see it. >> > > Thanks, but this is the one for your successful build. If you're willing, > could you please pass along the for failed configure (when you didn't have > --disable-metaphysicl)? Thanks! > > >> >> Thankfully, >> Harrison Rojak Pearce >> SDSU Undergraduate in Chemical Physics >> >> On Wed, Aug 1, 2018 at 1:34 PM, Paul T. Bauman <ptb...@gm...> >> wrote: >> >>> Thanks for the report. >>> >>> If you don't need metaphysicl, probably the quickest thing you can do is >>> pass `--disable-metaphysicl` >>> to libmesh configure. >>> >>> What compiler are you using? I wonder if it's too old to build that >>> boost module? >>> Could you send along your config.log (can send to me directly, the >>> mailing list will strip it). >>> I'm curious to see what caused that failure. >>> >>> On Wed, Aug 1, 2018 at 4:17 PM Harry Pearce <har...@gm...> >>> wrote: >>> >>>> Hello fellow libmesh users!, >>>> >>>> I am trying to configure libmesh 1.3.0. >>>> When I run ./configure I get the error: >>>> checking for Boost headers version >= 1.47.0... yes >>>> checking for Boost's header version... 1_55 >>>> checking for the toolset name used by Boost for mpicxx... configure: >>>> WARNING: could not figure out which toolset name to use for mpicxx >>>> >>>> checking for the flags needed to use pthreads... conftest.cpp: In >>>> function >>>> 'int main()': >>>> conftest.cpp:33:24: warning: null argument where non-null required >>>> (argument 1) [-Wnonnull] >>>> pthread_attr_init(0); pthread_cleanup_push(0, 0); >>>> ^ >>>> conftest.cpp:34:27: warning: null argument where non-null required >>>> (argument 1) [-Wnonnull] >>>> pthread_create(0,0,0,0); pthread_cleanup_pop(0); >>>> ^ >>>> conftest.cpp:34:27: warning: null argument where non-null required >>>> (argument 3) [-Wnonnull] >>>> conftest.cpp:32:34: warning: 'th' is used uninitialized in this function >>>> [-Wuninitialized] >>>> pthread_t th; pthread_join(th, 0); >>>> ^ >>>> -pthread >>>> configure: /vexcl/vexcl.hpp not found >>>> configure: /include/vexcl/vexcl.hpp not found >>>> checking whether we are using the Microsoft C++ compiler... no >>>> checking CL/cl.h usability... no >>>> checking CL/cl.h presence... no >>>> checking for CL/cl.h... no >>>> checking OpenCL/cl.h usability... no >>>> checking OpenCL/cl.h presence... no >>>> checking for OpenCL/cl.h... no >>>> checking windows.h usability... no >>>> checking windows.h presence... no >>>> checking for windows.h... no >>>> checking for OpenCL library... no >>>> checking boost/system/error_code.hpp usability... yes >>>> checking boost/system/error_code.hpp presence... yes >>>> checking for boost/system/error_code.hpp... yes >>>> checking for the Boost system library... yes >>>> checking boost/chrono.hpp usability... yes >>>> checking boost/chrono.hpp presence... yes >>>> checking for boost/chrono.hpp... yes >>>> checking for the Boost chrono library... (cached) yes >>>> checking boost/date_time/posix_time/posix_time.hpp usability... no >>>> checking boost/date_time/posix_time/posix_time.hpp presence... yes >>>> configure: WARNING: boost/date_time/posix_time/posix_time.hpp: present >>>> but >>>> cannot be compiled >>>> configure: WARNING: boost/date_time/posix_time/posix_time.hpp: >>>> check >>>> for missing prerequisite headers? >>>> configure: WARNING: boost/date_time/posix_time/posix_time.hpp: see the >>>> Autoconf documentation >>>> configure: WARNING: boost/date_time/posix_time/posix_time.hpp: >>>> section >>>> "Present But Cannot Be Compiled" >>>> configure: WARNING: boost/date_time/posix_time/posix_time.hpp: >>>> proceeding >>>> with the compiler's result >>>> configure: WARNING: ## --------------------------------------- ## >>>> configure: WARNING: ## Report this to roy...@ic... ## >>>> configure: WARNING: ## --------------------------------------- ## >>>> checking for boost/date_time/posix_time/posix_time.hpp... no >>>> configure: error: cannot find boost/date_time/posix_time/posix_time.hpp >>>> configure: error: ./configure failed for contrib/metaphysicl/0.2.0 >>>> >>>> I thought the problem may have had to do with the installation of mpich >>>> but I reinstalled it and the problem persists. I am wondering if the >>>> problem is with libmesh, boost, or something else. >>>> >>>> I have read over some of the entries relating to this problem, and they >>>> did >>>> not help, although there are alot of entries so if someone has already >>>> solved this problem and you can point me in the direction of their post, >>>> that also works. >>>> >>>> Thanks, >>>> Harrison Rojak Pearce >>>> SDSU undergraduate in Chemical Physics >>>> ------------------------------------------------------------ >>>> ------------------ >>>> Check out the vibrant tech community on one of the world's most >>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>> _______________________________________________ >>>> Libmesh-users mailing list >>>> Lib...@li... >>>> https://lists.sourceforge.net/lists/listinfo/libmesh-users >>>> >>> >> |
|
From: Paul T. B. <ptb...@gm...> - 2018-08-01 22:10:24
|
On Wed, Aug 1, 2018 at 5:50 PM Harry Pearce <har...@gm...> wrote: > Paul, > Thanks! Your recommendation worked! > Great, glad you got it working. Let us know if you run into other issues. > My config.log file is attached just in case you still want to see it. > Thanks, but this is the one for your successful build. If you're willing, could you please pass along the for failed configure (when you didn't have --disable-metaphysicl)? Thanks! > > Thankfully, > Harrison Rojak Pearce > SDSU Undergraduate in Chemical Physics > > On Wed, Aug 1, 2018 at 1:34 PM, Paul T. Bauman <ptb...@gm...> wrote: > >> Thanks for the report. >> >> If you don't need metaphysicl, probably the quickest thing you can do is >> pass `--disable-metaphysicl` >> to libmesh configure. >> >> What compiler are you using? I wonder if it's too old to build that boost >> module? >> Could you send along your config.log (can send to me directly, the >> mailing list will strip it). >> I'm curious to see what caused that failure. >> >> On Wed, Aug 1, 2018 at 4:17 PM Harry Pearce <har...@gm...> >> wrote: >> >>> Hello fellow libmesh users!, >>> >>> I am trying to configure libmesh 1.3.0. >>> When I run ./configure I get the error: >>> checking for Boost headers version >= 1.47.0... yes >>> checking for Boost's header version... 1_55 >>> checking for the toolset name used by Boost for mpicxx... configure: >>> WARNING: could not figure out which toolset name to use for mpicxx >>> >>> checking for the flags needed to use pthreads... conftest.cpp: In >>> function >>> 'int main()': >>> conftest.cpp:33:24: warning: null argument where non-null required >>> (argument 1) [-Wnonnull] >>> pthread_attr_init(0); pthread_cleanup_push(0, 0); >>> ^ >>> conftest.cpp:34:27: warning: null argument where non-null required >>> (argument 1) [-Wnonnull] >>> pthread_create(0,0,0,0); pthread_cleanup_pop(0); >>> ^ >>> conftest.cpp:34:27: warning: null argument where non-null required >>> (argument 3) [-Wnonnull] >>> conftest.cpp:32:34: warning: 'th' is used uninitialized in this function >>> [-Wuninitialized] >>> pthread_t th; pthread_join(th, 0); >>> ^ >>> -pthread >>> configure: /vexcl/vexcl.hpp not found >>> configure: /include/vexcl/vexcl.hpp not found >>> checking whether we are using the Microsoft C++ compiler... no >>> checking CL/cl.h usability... no >>> checking CL/cl.h presence... no >>> checking for CL/cl.h... no >>> checking OpenCL/cl.h usability... no >>> checking OpenCL/cl.h presence... no >>> checking for OpenCL/cl.h... no >>> checking windows.h usability... no >>> checking windows.h presence... no >>> checking for windows.h... no >>> checking for OpenCL library... no >>> checking boost/system/error_code.hpp usability... yes >>> checking boost/system/error_code.hpp presence... yes >>> checking for boost/system/error_code.hpp... yes >>> checking for the Boost system library... yes >>> checking boost/chrono.hpp usability... yes >>> checking boost/chrono.hpp presence... yes >>> checking for boost/chrono.hpp... yes >>> checking for the Boost chrono library... (cached) yes >>> checking boost/date_time/posix_time/posix_time.hpp usability... no >>> checking boost/date_time/posix_time/posix_time.hpp presence... yes >>> configure: WARNING: boost/date_time/posix_time/posix_time.hpp: present >>> but >>> cannot be compiled >>> configure: WARNING: boost/date_time/posix_time/posix_time.hpp: check >>> for missing prerequisite headers? >>> configure: WARNING: boost/date_time/posix_time/posix_time.hpp: see the >>> Autoconf documentation >>> configure: WARNING: boost/date_time/posix_time/posix_time.hpp: >>> section >>> "Present But Cannot Be Compiled" >>> configure: WARNING: boost/date_time/posix_time/posix_time.hpp: proceeding >>> with the compiler's result >>> configure: WARNING: ## --------------------------------------- ## >>> configure: WARNING: ## Report this to roy...@ic... ## >>> configure: WARNING: ## --------------------------------------- ## >>> checking for boost/date_time/posix_time/posix_time.hpp... no >>> configure: error: cannot find boost/date_time/posix_time/posix_time.hpp >>> configure: error: ./configure failed for contrib/metaphysicl/0.2.0 >>> >>> I thought the problem may have had to do with the installation of mpich >>> but I reinstalled it and the problem persists. I am wondering if the >>> problem is with libmesh, boost, or something else. >>> >>> I have read over some of the entries relating to this problem, and they >>> did >>> not help, although there are alot of entries so if someone has already >>> solved this problem and you can point me in the direction of their post, >>> that also works. >>> >>> Thanks, >>> Harrison Rojak Pearce >>> SDSU undergraduate in Chemical Physics >>> >>> ------------------------------------------------------------------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> Libmesh-users mailing list >>> Lib...@li... >>> https://lists.sourceforge.net/lists/listinfo/libmesh-users >>> >> > |
|
From: Harry P. <har...@gm...> - 2018-08-01 21:50:25
|
Paul, Thanks! Your recommendation worked! My config.log file is attached just in case you still want to see it. Thankfully, Harrison Rojak Pearce SDSU Undergraduate in Chemical Physics On Wed, Aug 1, 2018 at 1:34 PM, Paul T. Bauman <ptb...@gm...> wrote: > Thanks for the report. > > If you don't need metaphysicl, probably the quickest thing you can do is > pass `--disable-metaphysicl` > to libmesh configure. > > What compiler are you using? I wonder if it's too old to build that boost > module? > Could you send along your config.log (can send to me directly, the mailing > list will strip it). > I'm curious to see what caused that failure. > > On Wed, Aug 1, 2018 at 4:17 PM Harry Pearce <har...@gm...> > wrote: > >> Hello fellow libmesh users!, >> >> I am trying to configure libmesh 1.3.0. >> When I run ./configure I get the error: >> checking for Boost headers version >= 1.47.0... yes >> checking for Boost's header version... 1_55 >> checking for the toolset name used by Boost for mpicxx... configure: >> WARNING: could not figure out which toolset name to use for mpicxx >> >> checking for the flags needed to use pthreads... conftest.cpp: In function >> 'int main()': >> conftest.cpp:33:24: warning: null argument where non-null required >> (argument 1) [-Wnonnull] >> pthread_attr_init(0); pthread_cleanup_push(0, 0); >> ^ >> conftest.cpp:34:27: warning: null argument where non-null required >> (argument 1) [-Wnonnull] >> pthread_create(0,0,0,0); pthread_cleanup_pop(0); >> ^ >> conftest.cpp:34:27: warning: null argument where non-null required >> (argument 3) [-Wnonnull] >> conftest.cpp:32:34: warning: 'th' is used uninitialized in this function >> [-Wuninitialized] >> pthread_t th; pthread_join(th, 0); >> ^ >> -pthread >> configure: /vexcl/vexcl.hpp not found >> configure: /include/vexcl/vexcl.hpp not found >> checking whether we are using the Microsoft C++ compiler... no >> checking CL/cl.h usability... no >> checking CL/cl.h presence... no >> checking for CL/cl.h... no >> checking OpenCL/cl.h usability... no >> checking OpenCL/cl.h presence... no >> checking for OpenCL/cl.h... no >> checking windows.h usability... no >> checking windows.h presence... no >> checking for windows.h... no >> checking for OpenCL library... no >> checking boost/system/error_code.hpp usability... yes >> checking boost/system/error_code.hpp presence... yes >> checking for boost/system/error_code.hpp... yes >> checking for the Boost system library... yes >> checking boost/chrono.hpp usability... yes >> checking boost/chrono.hpp presence... yes >> checking for boost/chrono.hpp... yes >> checking for the Boost chrono library... (cached) yes >> checking boost/date_time/posix_time/posix_time.hpp usability... no >> checking boost/date_time/posix_time/posix_time.hpp presence... yes >> configure: WARNING: boost/date_time/posix_time/posix_time.hpp: present >> but >> cannot be compiled >> configure: WARNING: boost/date_time/posix_time/posix_time.hpp: check >> for missing prerequisite headers? >> configure: WARNING: boost/date_time/posix_time/posix_time.hpp: see the >> Autoconf documentation >> configure: WARNING: boost/date_time/posix_time/posix_time.hpp: >> section >> "Present But Cannot Be Compiled" >> configure: WARNING: boost/date_time/posix_time/posix_time.hpp: proceeding >> with the compiler's result >> configure: WARNING: ## --------------------------------------- ## >> configure: WARNING: ## Report this to roy...@ic... ## >> configure: WARNING: ## --------------------------------------- ## >> checking for boost/date_time/posix_time/posix_time.hpp... no >> configure: error: cannot find boost/date_time/posix_time/posix_time.hpp >> configure: error: ./configure failed for contrib/metaphysicl/0.2.0 >> >> I thought the problem may have had to do with the installation of mpich >> but I reinstalled it and the problem persists. I am wondering if the >> problem is with libmesh, boost, or something else. >> >> I have read over some of the entries relating to this problem, and they >> did >> not help, although there are alot of entries so if someone has already >> solved this problem and you can point me in the direction of their post, >> that also works. >> >> Thanks, >> Harrison Rojak Pearce >> SDSU undergraduate in Chemical Physics >> ------------------------------------------------------------ >> ------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Libmesh-users mailing list >> Lib...@li... >> https://lists.sourceforge.net/lists/listinfo/libmesh-users >> > |
|
From: Paul T. B. <ptb...@gm...> - 2018-08-01 20:34:45
|
Thanks for the report. If you don't need metaphysicl, probably the quickest thing you can do is pass `--disable-metaphysicl` to libmesh configure. What compiler are you using? I wonder if it's too old to build that boost module? Could you send along your config.log (can send to me directly, the mailing list will strip it). I'm curious to see what caused that failure. On Wed, Aug 1, 2018 at 4:17 PM Harry Pearce <har...@gm...> wrote: > Hello fellow libmesh users!, > > I am trying to configure libmesh 1.3.0. > When I run ./configure I get the error: > checking for Boost headers version >= 1.47.0... yes > checking for Boost's header version... 1_55 > checking for the toolset name used by Boost for mpicxx... configure: > WARNING: could not figure out which toolset name to use for mpicxx > > checking for the flags needed to use pthreads... conftest.cpp: In function > 'int main()': > conftest.cpp:33:24: warning: null argument where non-null required > (argument 1) [-Wnonnull] > pthread_attr_init(0); pthread_cleanup_push(0, 0); > ^ > conftest.cpp:34:27: warning: null argument where non-null required > (argument 1) [-Wnonnull] > pthread_create(0,0,0,0); pthread_cleanup_pop(0); > ^ > conftest.cpp:34:27: warning: null argument where non-null required > (argument 3) [-Wnonnull] > conftest.cpp:32:34: warning: 'th' is used uninitialized in this function > [-Wuninitialized] > pthread_t th; pthread_join(th, 0); > ^ > -pthread > configure: /vexcl/vexcl.hpp not found > configure: /include/vexcl/vexcl.hpp not found > checking whether we are using the Microsoft C++ compiler... no > checking CL/cl.h usability... no > checking CL/cl.h presence... no > checking for CL/cl.h... no > checking OpenCL/cl.h usability... no > checking OpenCL/cl.h presence... no > checking for OpenCL/cl.h... no > checking windows.h usability... no > checking windows.h presence... no > checking for windows.h... no > checking for OpenCL library... no > checking boost/system/error_code.hpp usability... yes > checking boost/system/error_code.hpp presence... yes > checking for boost/system/error_code.hpp... yes > checking for the Boost system library... yes > checking boost/chrono.hpp usability... yes > checking boost/chrono.hpp presence... yes > checking for boost/chrono.hpp... yes > checking for the Boost chrono library... (cached) yes > checking boost/date_time/posix_time/posix_time.hpp usability... no > checking boost/date_time/posix_time/posix_time.hpp presence... yes > configure: WARNING: boost/date_time/posix_time/posix_time.hpp: present but > cannot be compiled > configure: WARNING: boost/date_time/posix_time/posix_time.hpp: check > for missing prerequisite headers? > configure: WARNING: boost/date_time/posix_time/posix_time.hpp: see the > Autoconf documentation > configure: WARNING: boost/date_time/posix_time/posix_time.hpp: section > "Present But Cannot Be Compiled" > configure: WARNING: boost/date_time/posix_time/posix_time.hpp: proceeding > with the compiler's result > configure: WARNING: ## --------------------------------------- ## > configure: WARNING: ## Report this to roy...@ic... ## > configure: WARNING: ## --------------------------------------- ## > checking for boost/date_time/posix_time/posix_time.hpp... no > configure: error: cannot find boost/date_time/posix_time/posix_time.hpp > configure: error: ./configure failed for contrib/metaphysicl/0.2.0 > > I thought the problem may have had to do with the installation of mpich > but I reinstalled it and the problem persists. I am wondering if the > problem is with libmesh, boost, or something else. > > I have read over some of the entries relating to this problem, and they did > not help, although there are alot of entries so if someone has already > solved this problem and you can point me in the direction of their post, > that also works. > > Thanks, > Harrison Rojak Pearce > SDSU undergraduate in Chemical Physics > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Libmesh-users mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-users > |
|
From: Harry P. <har...@gm...> - 2018-08-01 20:17:33
|
Hello fellow libmesh users!,
I am trying to configure libmesh 1.3.0.
When I run ./configure I get the error:
checking for Boost headers version >= 1.47.0... yes
checking for Boost's header version... 1_55
checking for the toolset name used by Boost for mpicxx... configure:
WARNING: could not figure out which toolset name to use for mpicxx
checking for the flags needed to use pthreads... conftest.cpp: In function
'int main()':
conftest.cpp:33:24: warning: null argument where non-null required
(argument 1) [-Wnonnull]
pthread_attr_init(0); pthread_cleanup_push(0, 0);
^
conftest.cpp:34:27: warning: null argument where non-null required
(argument 1) [-Wnonnull]
pthread_create(0,0,0,0); pthread_cleanup_pop(0);
^
conftest.cpp:34:27: warning: null argument where non-null required
(argument 3) [-Wnonnull]
conftest.cpp:32:34: warning: 'th' is used uninitialized in this function
[-Wuninitialized]
pthread_t th; pthread_join(th, 0);
^
-pthread
configure: /vexcl/vexcl.hpp not found
configure: /include/vexcl/vexcl.hpp not found
checking whether we are using the Microsoft C++ compiler... no
checking CL/cl.h usability... no
checking CL/cl.h presence... no
checking for CL/cl.h... no
checking OpenCL/cl.h usability... no
checking OpenCL/cl.h presence... no
checking for OpenCL/cl.h... no
checking windows.h usability... no
checking windows.h presence... no
checking for windows.h... no
checking for OpenCL library... no
checking boost/system/error_code.hpp usability... yes
checking boost/system/error_code.hpp presence... yes
checking for boost/system/error_code.hpp... yes
checking for the Boost system library... yes
checking boost/chrono.hpp usability... yes
checking boost/chrono.hpp presence... yes
checking for boost/chrono.hpp... yes
checking for the Boost chrono library... (cached) yes
checking boost/date_time/posix_time/posix_time.hpp usability... no
checking boost/date_time/posix_time/posix_time.hpp presence... yes
configure: WARNING: boost/date_time/posix_time/posix_time.hpp: present but
cannot be compiled
configure: WARNING: boost/date_time/posix_time/posix_time.hpp: check
for missing prerequisite headers?
configure: WARNING: boost/date_time/posix_time/posix_time.hpp: see the
Autoconf documentation
configure: WARNING: boost/date_time/posix_time/posix_time.hpp: section
"Present But Cannot Be Compiled"
configure: WARNING: boost/date_time/posix_time/posix_time.hpp: proceeding
with the compiler's result
configure: WARNING: ## --------------------------------------- ##
configure: WARNING: ## Report this to roy...@ic... ##
configure: WARNING: ## --------------------------------------- ##
checking for boost/date_time/posix_time/posix_time.hpp... no
configure: error: cannot find boost/date_time/posix_time/posix_time.hpp
configure: error: ./configure failed for contrib/metaphysicl/0.2.0
I thought the problem may have had to do with the installation of mpich
but I reinstalled it and the problem persists. I am wondering if the
problem is with libmesh, boost, or something else.
I have read over some of the entries relating to this problem, and they did
not help, although there are alot of entries so if someone has already
solved this problem and you can point me in the direction of their post,
that also works.
Thanks,
Harrison Rojak Pearce
SDSU undergraduate in Chemical Physics
|
|
From: Roy S. <roy...@ic...> - 2018-07-24 13:29:27
|
On Tue, 24 Jul 2018, Nikhil Vaidya wrote: > Thanks for the answer. I tried removing the particular initialize call and > ran it again. This time I get the following error message: > > Assertion `proc < _first_df.size()' failed. > proc = 0 > _first_df.size() = 0 That's an assertion failure from the DofMap being uninitialized, which would mean the whole System hasn't been initialized. It looks as if you've somehow gone from 2 initializations straight to 0. (or to 1 initialization which comes too late) --- Roy |
|
From: David K. <dav...@ak...> - 2018-07-24 12:38:10
|
On Tue, Jul 24, 2018 at 2:29 AM, Nikhil Vaidya <nik...@gm...> wrote: > Thanks for the answer. I tried removing the particular initialize call and > ran it again. This time I get the following error message: > > Assertion `proc < _first_df.size()' failed. > proc = 0 > _first_df.size() = 0 > > > Detaching after fork from child process 10172. > Stack frames: 17 > 0: libMesh::print_trace(std::ostream&) > 1: libMesh::MacroFunctions::report_error(char const*, int, char const*, > char const*) > 2: libMesh::DofMap::n_dofs_on_processor(unsigned short) const > 3: libMesh::PetscMatrix<double>::init() > 4: libMesh::RBConstruction::allocate_data_structures() > 5: libMesh::RBConstruction::initialize_rb_construction(bool, bool) > 6: libMesh::RBEIMConstruction::initialize_rb_construction(bool, bool) > 7: DwarfElephantInitializeRBSystemSteadyState::initializeOfflineStage() > 8: DwarfElephantInitializeRBSystemSteadyState::initialize() > 9: FEProblemBase::computeUserObjects(MooseEnumItem const&, Moose::AuxGroup > const&) > 10: FEProblemBase::initialSetup() > 11: DwarfElephantRBExecutioner::init() > 12: MooseApp::executeExecutioner() > 13: MooseApp::run() > 14: > /home/2014-0004_focal_therapy/PhDs/AdapTT/Nikhil/ > DwarfElephant/./DwarfElephant-dbg() > [0x40d0b5] > 15: __libc_start_main > 16: > /home/2014-0004_focal_therapy/PhDs/AdapTT/Nikhil/ > DwarfElephant/./DwarfElephant-dbg() > [0x40cf02] > [0] > /home/2014-0004_focal_therapy/PhDs/AdapTT/Nikhil/moose/ > scripts/../libmesh/installed/include/libmesh/dof_map.h, > line 545, compiled Jul 17 2018 at 13:35:22 > application called MPI_Abort(MPI_COMM_WORLD, 1) - process 0 > [unset]: write_line error; fd=-1 buf=:cmd=abort exitcode=1 > : > system msg for write_line failure : Bad file descriptor > > > I will give a little more information about what it is I am trying to do. I > have created RBConstruction, RBEIMConstruction, RBEvaluation and > RBEIMEvaluation classes of my own. I have also created structures for the > theta objects. Instead of creating rb and eim assembly objects, I am > assembling the rb and eim matrices over MOOSE. To do this, I initialize the > eim and rb construction objects by skipping matrix and vector assemblies. I > can give more details about my implementation. Since I am not very familiar > with the inner workings of libMesh, I am finding it difficult to debug the > libMesh related parts of my code. > It looks like something is uninitialized, but unfortunately I can't tell what it would be based on your description. You said that you skip matrix and vector assemblies, so that could lead to some uninitialized data. Have you reviewed reduced_basis_ex4 and tried to mimic the approach that is used there? (I guess you have since you said you created your own subclasses of the EIM classes.) Best, David On Mon, Jul 23, 2018 at 2:51 PM, Roy Stogner <roy...@ic...> wrote: > > On Mon, 23 Jul 2018, Nikhil Vaidya wrote: > > Starting InitializeRB::initialize() >> Assertion `!this->is_initialized()' failed. >> >> Detaching after fork from child process 17473. >> Stack frames: 13 >> 0: libMesh::print_trace(std::ostream&) >> 1: libMesh::MacroFunctions::report_error(char const*, int, char const*, >> char const*) >> 2: libMesh::System::init() >> > > In DwarfElephant, I am calling all the funtions called in the libMesh >> example 4 as they are. What could be the problem? >> > > The superficial problem looks simple enough: your System object(s) > already had init called (whether directly or via a data read) and now > your new class is trying to call init on them again. > > The root problem and fix depends on exactly what you're trying to do > there. > --- > Roy > ------------------------------------------------------------ ------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Libmesh-users mailing list Lib...@li... https://lists.sourceforge.net/lists/listinfo/libmesh-users |
|
From: Nikhil V. <nik...@gm...> - 2018-07-24 06:29:23
|
Thanks for the answer. I tried removing the particular initialize call and ran it again. This time I get the following error message: Assertion `proc < _first_df.size()' failed. proc = 0 _first_df.size() = 0 Detaching after fork from child process 10172. Stack frames: 17 0: libMesh::print_trace(std::ostream&) 1: libMesh::MacroFunctions::report_error(char const*, int, char const*, char const*) 2: libMesh::DofMap::n_dofs_on_processor(unsigned short) const 3: libMesh::PetscMatrix<double>::init() 4: libMesh::RBConstruction::allocate_data_structures() 5: libMesh::RBConstruction::initialize_rb_construction(bool, bool) 6: libMesh::RBEIMConstruction::initialize_rb_construction(bool, bool) 7: DwarfElephantInitializeRBSystemSteadyState::initializeOfflineStage() 8: DwarfElephantInitializeRBSystemSteadyState::initialize() 9: FEProblemBase::computeUserObjects(MooseEnumItem const&, Moose::AuxGroup const&) 10: FEProblemBase::initialSetup() 11: DwarfElephantRBExecutioner::init() 12: MooseApp::executeExecutioner() 13: MooseApp::run() 14: /home/2014-0004_focal_therapy/PhDs/AdapTT/Nikhil/DwarfElephant/./DwarfElephant-dbg() [0x40d0b5] 15: __libc_start_main 16: /home/2014-0004_focal_therapy/PhDs/AdapTT/Nikhil/DwarfElephant/./DwarfElephant-dbg() [0x40cf02] [0] /home/2014-0004_focal_therapy/PhDs/AdapTT/Nikhil/moose/scripts/../libmesh/installed/include/libmesh/dof_map.h, line 545, compiled Jul 17 2018 at 13:35:22 application called MPI_Abort(MPI_COMM_WORLD, 1) - process 0 [unset]: write_line error; fd=-1 buf=:cmd=abort exitcode=1 : system msg for write_line failure : Bad file descriptor I will give a little more information about what it is I am trying to do. I have created RBConstruction, RBEIMConstruction, RBEvaluation and RBEIMEvaluation classes of my own. I have also created structures for the theta objects. Instead of creating rb and eim assembly objects, I am assembling the rb and eim matrices over MOOSE. To do this, I initialize the eim and rb construction objects by skipping matrix and vector assemblies. I can give more details about my implementation. Since I am not very familiar with the inner workings of libMesh, I am finding it difficult to debug the libMesh related parts of my code. Best regards, Nikhil On Mon, Jul 23, 2018 at 2:51 PM, Roy Stogner <roy...@ic...> wrote: > > On Mon, 23 Jul 2018, Nikhil Vaidya wrote: > > Starting InitializeRB::initialize() >> Assertion `!this->is_initialized()' failed. >> >> Detaching after fork from child process 17473. >> Stack frames: 13 >> 0: libMesh::print_trace(std::ostream&) >> 1: libMesh::MacroFunctions::report_error(char const*, int, char const*, >> char const*) >> 2: libMesh::System::init() >> > > In DwarfElephant, I am calling all the funtions called in the libMesh >> example 4 as they are. What could be the problem? >> > > The superficial problem looks simple enough: your System object(s) > already had init called (whether directly or via a data read) and now > your new class is trying to call init on them again. > > The root problem and fix depends on exactly what you're trying to do > there. > --- > Roy > |
|
From: Roy S. <roy...@ic...> - 2018-07-23 12:52:02
|
On Mon, 23 Jul 2018, Nikhil Vaidya wrote: > Starting InitializeRB::initialize() > Assertion `!this->is_initialized()' failed. > > Detaching after fork from child process 17473. > Stack frames: 13 > 0: libMesh::print_trace(std::ostream&) > 1: libMesh::MacroFunctions::report_error(char const*, int, char const*, > char const*) > 2: libMesh::System::init() > In DwarfElephant, I am calling all the funtions called in the libMesh > example 4 as they are. What could be the problem? The superficial problem looks simple enough: your System object(s) already had init called (whether directly or via a data read) and now your new class is trying to call init on them again. The root problem and fix depends on exactly what you're trying to do there. --- Roy |
|
From: Nikhil V. <nik...@gm...> - 2018-07-23 09:39:26
|
I am using a MOOSE app called DwarfElephant that allows the use of the libMesh Reduced Basis functionality in MOOSE. The app can currently handle reduced order modeling with material parameters. I am trying to extend the app to include the EIM functionality of libMesh. I have implemented example 4 of libMesh reduced basis in DwarfElephant. I am facing some runtime errors. When I run the code, it stops at with a failed assertion '!this->is_initialized()'. The stack trace is below. Starting InitializeRB::initialize() Assertion `!this->is_initialized()' failed. Detaching after fork from child process 17473. Stack frames: 13 0: libMesh::print_trace(std::ostream&) 1: libMesh::MacroFunctions::report_error(char const*, int, char const*, char const*) 2: libMesh::System::init() 3: libMesh::EquationSystems::init() 4: DwarfElephantInitializeRBSystemSteadyState::initialize() 5: FEProblemBase::computeUserObjects(MooseEnumItem const&, Moose::AuxGroup const&) 6: FEProblemBase::initialSetup() 7: DwarfElephantRBExecutioner::init() 8: MooseApp::executeExecutioner() 9: MooseApp::run() 10: /home/2014-0004_focal_therapy/PhDs/AdapTT/Nikhil/DwarfElephant/./DwarfElephant-dbg() [0x40d0b5] 11: __libc_start_main 12: /home/2014-0004_focal_therapy/PhDs/AdapTT/Nikhil/DwarfElephant/./DwarfElephant-dbg() [0x40cf02] [0] ../src/systems/system.C, line 240, compiled Jul 3 2018 at 15:01:06 application called MPI_Abort(MPI_COMM_WORLD, 1) - process 0 [unset]: write_line error; fd=-1 buf=:cmd=abort exitcode=1 : system msg for write_line failure : Bad file descriptor In DwarfElephant, I am calling all the funtions called in the libMesh example 4 as they are. What could be the problem? Best regards, Nikhil |
|
From: Boris B. <bor...@bu...> - 2018-07-17 13:41:28
|
Thanks for the info, I was trying to profile something simple for starters so went with intro/ex3. You were right in that I wasn't compiling PETSc with -pg, but unfortunately that seemed to be only part of the problem. I ended up having to configure libMesh with --disable-shared --enable-static and with these changes the produced perf logs seem to behave as expected - as this satisfies my needs Ill just stick with this configuration for now. Thanks again, Boris On Tue, Jul 10, 2018 at 10:50 PM, Roy Stogner <roy...@ic...> wrote: > > On Tue, 10 Jul 2018, Boris Boutkov wrote: > > Oh, that's unfortunate. I've uploaded the logs in question to a public >> google drive folder, they should be available for download at : >> >> https://drive.google.com/drive/u/1/folders/1-FqKx9FhtSgRAttG >> VW-4cYNUfzehbpTz >> > > The PerfLog in intro_ex3.log says 97.66% of your time is being spent > in PetscLinearSolver::solve(). What exactly are you trying to profile > here? There's not even any time spent within PerfLog'ed subroutines > called from within solve(), so you can't be doing a multigrid sweep > here, can you? > > If you're not compiling PETSc with -pg that would explain where 97.66% > of your runtime vanished in the gprof output, but I don't see why 99% > of your *call graph* seems to have vanished. That gprof.log looks as > if you linked a METHOD=prof compiled example against a METHOD=opt > compiled libMesh somehow. > --- > Roy > |
|
From: Derek G. <fri...@gm...> - 2018-07-15 22:28:04
|
MOOSE has had this for a long time - you can see how we do it here: https://github.com/idaholab/moose/blob/devel/framework/src/problems/FEProblemBase.C#L4651 Basically: 1. Indicate/Mark 2. Adapt 3. Reinit and re-project 4. Repeat Derek On Sun, Jul 15, 2018 at 1:55 PM Vinicius C. Reis <vin...@co...> wrote: > Hi Roy, my problem is pretty simple so the workaround you've suggested will > work perfectly fine. For now, since I'm testing only simple geometries it > might suffice to do all refinement before solving, so no post solve > projection would even be necessary. If I have the chance to implement any > complex geometry I'll disable the mesh-to-mesh projection and see how it > goes. But I have to say, being able to restrict the boundary intersection > to a subdomain would be a great easy in the computational effort required. > > As for the value of newly created elements, I'm not sure if initializing > the new dofs to zero would be enough. At least in (not actually) my > formulation, surrogate boundary, the new dofs will have to be mapped from > the real boundary to the surrogated one. For steady problems, this is not a > problem since the boundary conditions are taken into account in the > variational statement itself. The challenge might be in transient and > multiphysics problems in which there's a moving boundary (the actual > interesting problems). Assuming zero previous values on time integration > might not the right thing. But I have to admit I'm just guessing at this > point. > > Anyways, a general solution I can think is to leave the user with the > option of setting a function object (lambda function would be my > preference) that will be used to evaluate the value of the newly inserted > dofs. > > I hope this makes sense. > > Best regards, > Vinícius Reis > > 2018-06-29 11:46 GMT-03:00 Roy Stogner <roy...@ic...>: > > > > > On Thu, 28 Jun 2018, Roy Stogner wrote: > > > > On Tue, 12 Jun 2018, Vinicius C. Reis wrote: > >> > >> Hi John, I pasted a somewhat smaller version of my code below. By > playing > >>> with the refinement steps limit and the commented out init() and > >>> reinit() > >>> lines you should be able to reproduce the two exceptions I got. > >>> > >> > >> We could try to start treating that the way we currently treat element > >> addition mid-simulation: all the newly created DoFs get coefficients > >> initialized to zero. I assume that's the behavior you're hoping for? > >> > > > > Oh, just in case it helps: all my "how do we interpret this, how do we > > implement this" confusion only applies to the projection step. If > > you're solving a steady problem then a quick-and-dirty workaround for > > that case would be to just disable mesh-to-mesh projections and redo > > the solve from scratch after each refinement step. > > --- > > Roy > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Libmesh-users mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-users > |
|
From: Vinicius C. R. <vin...@co...> - 2018-07-15 19:54:33
|
Hi Roy, my problem is pretty simple so the workaround you've suggested will work perfectly fine. For now, since I'm testing only simple geometries it might suffice to do all refinement before solving, so no post solve projection would even be necessary. If I have the chance to implement any complex geometry I'll disable the mesh-to-mesh projection and see how it goes. But I have to say, being able to restrict the boundary intersection to a subdomain would be a great easy in the computational effort required. As for the value of newly created elements, I'm not sure if initializing the new dofs to zero would be enough. At least in (not actually) my formulation, surrogate boundary, the new dofs will have to be mapped from the real boundary to the surrogated one. For steady problems, this is not a problem since the boundary conditions are taken into account in the variational statement itself. The challenge might be in transient and multiphysics problems in which there's a moving boundary (the actual interesting problems). Assuming zero previous values on time integration might not the right thing. But I have to admit I'm just guessing at this point. Anyways, a general solution I can think is to leave the user with the option of setting a function object (lambda function would be my preference) that will be used to evaluate the value of the newly inserted dofs. I hope this makes sense. Best regards, Vinícius Reis 2018-06-29 11:46 GMT-03:00 Roy Stogner <roy...@ic...>: > > On Thu, 28 Jun 2018, Roy Stogner wrote: > > On Tue, 12 Jun 2018, Vinicius C. Reis wrote: >> >> Hi John, I pasted a somewhat smaller version of my code below. By playing >>> with the refinement steps limit and the commented out init() and >>> reinit() >>> lines you should be able to reproduce the two exceptions I got. >>> >> >> We could try to start treating that the way we currently treat element >> addition mid-simulation: all the newly created DoFs get coefficients >> initialized to zero. I assume that's the behavior you're hoping for? >> > > Oh, just in case it helps: all my "how do we interpret this, how do we > implement this" confusion only applies to the projection step. If > you're solving a steady problem then a quick-and-dirty workaround for > that case would be to just disable mesh-to-mesh projections and redo > the solve from scratch after each refinement step. > --- > Roy > |
|
From: Roy S. <roy...@ic...> - 2018-07-11 02:50:11
|
On Tue, 10 Jul 2018, Boris Boutkov wrote: > Oh, that's unfortunate. I've uploaded the logs in question to a public google drive folder, they should be available for download at : > > https://drive.google.com/drive/u/1/folders/1-FqKx9FhtSgRAttGVW-4cYNUfzehbpTz The PerfLog in intro_ex3.log says 97.66% of your time is being spent in PetscLinearSolver::solve(). What exactly are you trying to profile here? There's not even any time spent within PerfLog'ed subroutines called from within solve(), so you can't be doing a multigrid sweep here, can you? If you're not compiling PETSc with -pg that would explain where 97.66% of your runtime vanished in the gprof output, but I don't see why 99% of your *call graph* seems to have vanished. That gprof.log looks as if you linked a METHOD=prof compiled example against a METHOD=opt compiled libMesh somehow. --- Roy |
|
From: Boris B. <bor...@bu...> - 2018-07-11 01:31:17
|
Oh, that's unfortunate. I've uploaded the logs in question to a public google drive folder, they should be available for download at : https://drive.google.com/drive/u/1/folders/1-FqKx9FhtSgRAttGVW-4cYNUfzehbpTz On Tue, Jul 10, 2018 at 4:41 PM, Roy Stogner <roy...@ic...> wrote: > > On Fri, 6 Jul 2018, Boris Boutkov wrote: > > I've been trying to do some profiling of some of the libMesh examples and >> am having some issues understanding the generated gprof output. It seems >> like much of the data that I am expecting is missing from the output >> (please see attached logs). >> > > Could you send me a copy of the logs privately, or better paste them > up on the web? I'm afraid our mailing list strips attachments. > --- > Roy > |
|
From: Roy S. <roy...@ic...> - 2018-07-10 20:41:16
|
On Fri, 6 Jul 2018, Boris Boutkov wrote: > I've been trying to do some profiling of some of the libMesh examples and > am having some issues understanding the generated gprof output. It seems > like much of the data that I am expecting is missing from the output > (please see attached logs). Could you send me a copy of the logs privately, or better paste them up on the web? I'm afraid our mailing list strips attachments. --- Roy |
|
From: <ss...@pu...> - 2018-07-10 01:21:17
|
Thank you very much! The “rb_con.load_rb_solution()” is the answer I want. I have not seen RB examples because I mistakenly thought that there was only content with exodus extension in examples. So I have only looked at LibMesh documentation and have searched a “solution” keyword. Thanks again for your kind answers to minor questions. Regards, SKang From: David Knezevic <dav...@ak...> Sent: Tuesday, July 10, 2018 9:52 AM To: 강신성 <ss...@pu...> Cc: libmesh-users <lib...@li...> Subject: Re: [Libmesh-users] [RB] Print solution vector as ".txt" On Mon, Jul 9, 2018 at 8:43 PM, <ss...@pu... <mailto:ss...@pu...> > wrote: Thank you for your reply, David I think my question was unclear. My final goal is the same as the question. However, before I print solutions using “cout” or “I/O,” I do not know which variable the solution vector is stored in. In other words, which variable can I use to load solutions of a PDE in RB codes? I also want to know which variable stores nodes that match the above solutions. I look forward your reply. I'm not sure I understand what you're asking, but in general I'd suggest you review the reduced_basis examples carefully since that should cover what you're asking about. For example, see the "online stage" of reduced_basis_ex1, where we do "rb_con.load_rb_solution()". This loads the RB solution into the "solution" vector of the RBConstruction object. Best, David From: David Knezevic <dav...@ak... <mailto:dav...@ak...> > Sent: Monday, July 9, 2018 9:12 PM To: 강신성 <ss...@pu... <mailto:ss...@pu...> > Cc: libmesh-users <lib...@li... <mailto:lib...@li...> > Subject: Re: [Libmesh-users] [RB] Print solution vector as ".txt" On Sun, Jul 8, 2018 at 10:53 PM, <ss...@pu... <mailto:ss...@pu...> > wrote: Hello, all. To find the maximum solution value, I try to print a solution vector, e.g., displacement vector in linear elasticity, as text extension. However, I was able to find only the solution with the exodus extension. This exodus extension is useful to visualize with a program like "ParaView," but it is complicated to compare results directly. So I want to print solution with ".txt" as follows: (node) (solution) 1 0.1122 2 0.5454 . 3224 0.5722 If there are multiple solutions such as 2D elasticity (displacements for x and y directions), I want to print a text file as (node) (x) (y) 1 0.1122 0.5556 2 0.5454 0.5878 . 3224 0.5722 0.4125 Could you please tell me some ways or ideas? If it is impossible, I want to print the maximum solution value in "Terminal" using "std::cout << . << std::endl" at least. I always thank you for your help. I gather you're asking how to write to a .txt file? That is a C++ question, not specifically related to libMesh. I suggest you look on the web for a tutorial for I/O, e.g. http://www.cplusplus.com/doc/tutorial/files/ Best, David |
|
From: David K. <dav...@ak...> - 2018-07-10 00:52:17
|
On Mon, Jul 9, 2018 at 8:43 PM, <ss...@pu...> wrote: > Thank you for your reply, David > > > > I think my question was unclear. > > > > My final goal is the same as the question. > > However, before I print solutions using “cout” or “I/O,” I do not know > which variable the solution vector is stored in. > > In other words, which variable can I use to load solutions of a PDE in RB > codes? > > I also want to know which variable stores nodes that match the above > solutions. > > > > I look forward your reply. > I'm not sure I understand what you're asking, but in general I'd suggest you review the reduced_basis examples carefully since that should cover what you're asking about. For example, see the "online stage" of reduced_basis_ex1, where we do "rb_con.load_rb_solution()". This loads the RB solution into the "solution" vector of the RBConstruction object. Best, David > > > *From:* David Knezevic <dav...@ak...> > *Sent:* Monday, July 9, 2018 9:12 PM > *To:* 강신성 <ss...@pu...> > *Cc:* libmesh-users <lib...@li...> > *Subject:* Re: [Libmesh-users] [RB] Print solution vector as ".txt" > > > > On Sun, Jul 8, 2018 at 10:53 PM, <ss...@pu...> wrote: > > Hello, all. > > > > To find the maximum solution value, I try to print a solution vector, e.g., > displacement vector in linear elasticity, as text extension. > > However, I was able to find only the solution with the exodus extension. > > > > This exodus extension is useful to visualize with a program like > "ParaView," > but it is complicated to compare results directly. > > So I want to print solution with ".txt" as follows: > > > > (node) (solution) > > 1 0.1122 > > 2 0.5454 > > . > > 3224 0.5722 > > > > If there are multiple solutions such as 2D elasticity (displacements for x > and y directions), I want to print a text file as > > > > (node) (x) (y) > > 1 0.1122 0.5556 > > 2 0.5454 0.5878 > > . > > 3224 0.5722 0.4125 > > > > Could you please tell me some ways or ideas? > > If it is impossible, I want to print the maximum solution value in > "Terminal" using "std::cout << . << std::endl" at least. > > > > I always thank you for your help. > > > > > > I gather you're asking how to write to a .txt file? That is a C++ > question, not specifically related to libMesh. I suggest you look on the > web for a tutorial for I/O, e.g. http://www.cplusplus.com/ > doc/tutorial/files/ > > > > Best, > David > |
|
From: <ss...@pu...> - 2018-07-10 00:46:14
|
Thank you for your reply, David I think my question was unclear. My final goal is the same as the question. However, before I print solutions using “cout” or “I/O,” I do not know which variable the solution vector is stored in. In other words, which variable can I use to load solutions of a PDE in RB codes? I also want to know which variable stores nodes that match the above solutions. I look forward your reply. Regards, SKang From: David Knezevic <dav...@ak...> Sent: Monday, July 9, 2018 9:12 PM To: 강신성 <ss...@pu...> Cc: libmesh-users <lib...@li...> Subject: Re: [Libmesh-users] [RB] Print solution vector as ".txt" On Sun, Jul 8, 2018 at 10:53 PM, <ss...@pu... <mailto:ss...@pu...> > wrote: Hello, all. To find the maximum solution value, I try to print a solution vector, e.g., displacement vector in linear elasticity, as text extension. However, I was able to find only the solution with the exodus extension. This exodus extension is useful to visualize with a program like "ParaView," but it is complicated to compare results directly. So I want to print solution with ".txt" as follows: (node) (solution) 1 0.1122 2 0.5454 . 3224 0.5722 If there are multiple solutions such as 2D elasticity (displacements for x and y directions), I want to print a text file as (node) (x) (y) 1 0.1122 0.5556 2 0.5454 0.5878 . 3224 0.5722 0.4125 Could you please tell me some ways or ideas? If it is impossible, I want to print the maximum solution value in "Terminal" using "std::cout << . << std::endl" at least. I always thank you for your help. I gather you're asking how to write to a .txt file? That is a C++ question, not specifically related to libMesh. I suggest you look on the web for a tutorial for I/O, e.g. http://www.cplusplus.com/doc/tutorial/files/ Best, David |
|
From: David K. <dav...@ak...> - 2018-07-09 12:12:15
|
On Sun, Jul 8, 2018 at 10:53 PM, <ss...@pu...> wrote: > Hello, all. > > > > To find the maximum solution value, I try to print a solution vector, e.g., > displacement vector in linear elasticity, as text extension. > > However, I was able to find only the solution with the exodus extension. > > > > This exodus extension is useful to visualize with a program like > "ParaView," > but it is complicated to compare results directly. > > So I want to print solution with ".txt" as follows: > > > > (node) (solution) > > 1 0.1122 > > 2 0.5454 > > . > > 3224 0.5722 > > > > If there are multiple solutions such as 2D elasticity (displacements for x > and y directions), I want to print a text file as > > > > (node) (x) (y) > > 1 0.1122 0.5556 > > 2 0.5454 0.5878 > > . > > 3224 0.5722 0.4125 > > > > Could you please tell me some ways or ideas? > > If it is impossible, I want to print the maximum solution value in > "Terminal" using "std::cout << . << std::endl" at least. > > > > I always thank you for your help. > I gather you're asking how to write to a .txt file? That is a C++ question, not specifically related to libMesh. I suggest you look on the web for a tutorial for I/O, e.g. http://www.cplusplus.com/doc/tutorial/files/ Best, David |
197 messages has been excluded from this view by a project administrator.
