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: Ata o. M. <a.m...@gm...> - 2023-12-22 21:13:40
|
Hi, I'm trying to set the solution of a DG0 variable in an ExplicitSystem (which I use for material properties) from a text (or CSV or really anything else I can generate in Python) file. I saw that Moose has something similar in ElementIDInterface <https://mooseframework.inl.gov/source/interfaces/ElementIDInterface.html>. I'm not using distributed mesh for now, so each processor should have the whole mesh, which I read from an exodusII file. Is there a way to access element numbers in the exodus file (elem_num_map) given the element pointer? Would you happen to have any better suggestions? Thank you, Ata |
From: INTURU S. 2. <int...@vi...> - 2023-09-03 07:16:36
|
Hi John, With the information you gave, I tried to install the latest libmesh version 1.7.1 and it was successful. Thanks for your valuable suggestions and the support. With regards Srinivas On Fri, Sep 1, 2023 at 8:22 PM John Peterson <jwp...@gm...> wrote: > > > On Fri, Sep 1, 2023 at 1:25 AM INTURU SRINIVAS 20PHD0548 < > int...@vi...> wrote: > >> Hi John, >> >> I tried with PETSC_DIR=/home/hpcsmec15767/sfw/petsc/3.17.5. I got the >> same error as mentioned below >> checking for built-in XDR support... yes >> checking >> /home/hpcsmec15767/sfw/petsc/3.17.5/linux-debug/include/petscversion.h >> usability... no >> checking >> /home/hpcsmec15767/sfw/petsc/3.17.5/linux-debug/include/petscversion.h >> presence... no >> checking for >> /home/hpcsmec15767/sfw/petsc/3.17.5/linux-debug/include/petscversion.h... no >> checking /home/hpcsmec15767/sfw/petsc/3.17.5/include/petscversion.h >> usability... no >> checking /home/hpcsmec15767/sfw/petsc/3.17.5/include/petscversion.h >> presence... no >> checking for >> /home/hpcsmec15767/sfw/petsc/3.17.5/include/petscversion.h... no >> configure: error: *** PETSc was not found, but --enable-petsc-required >> was specified. >> >> This one I am trying in the hpc cluster. Few months ago, I tried to >> install this IBAMR-0.13.0 open software with petsc 3.17.5 and libmesh 1.6.2 >> in our local machine, the same error occurred though. >> Right now I am using IBAMR-0.11.0 with petsc 3.13.4 and libmesh 1.6.2 and >> it is working in our local machine. >> > > > Does petsc 3.17.5 version compatible with libmesh 1.6.2? >> > > The PETSc 3.17.x release series was started in March 2022 > > commit 30c35bf2dfad782abeabcf00da45fe2af1c737cf (tag: v3.17.0) >> Author: Satish Balay <ba...@mc...> >> Date: Wed Mar 30 20:50:56 2022 -0500 > > > While libmesh 1.6.2 is from August 2021: > > commit e98f7419bd062d4c6b3cc3727899e892915af730 (tag: v1.6.2) >> Author: John W. Peterson <jwp...@gm...> >> Date: Mon Aug 2 14:59:29 2021 -0500 > > > so it predates PETSc 3.17 by several months. Therefore it's definitely > possible they are not compatible. Out of curiosity, where is petscversion.h > actually located in your installation of PETSc, since it is not located in > any of the places listed above? Also, how exactly do you install PETSc? If > you follow the directions that are printed to the screen when building > PETSc from source then the PETSc headers should just be located at > $PETSC_DIR/include and $PETSC_ARCH is not needed/used by libmesh configure. > > -- > John > -- **Disclaimer:* This message was sent from Vellore Institute of Technology. The contents of this email may contain legally protected confidential or privileged information of “Vellore Institute of Technology”. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. If you have received this email in error, please promptly notify the sender by reply email and delete the original email and any backup copies without reading them.* |
From: John P. <jwp...@gm...> - 2023-09-01 14:52:36
|
On Fri, Sep 1, 2023 at 1:25 AM INTURU SRINIVAS 20PHD0548 < int...@vi...> wrote: > Hi John, > > I tried with PETSC_DIR=/home/hpcsmec15767/sfw/petsc/3.17.5. I got the > same error as mentioned below > checking for built-in XDR support... yes > checking > /home/hpcsmec15767/sfw/petsc/3.17.5/linux-debug/include/petscversion.h > usability... no > checking > /home/hpcsmec15767/sfw/petsc/3.17.5/linux-debug/include/petscversion.h > presence... no > checking for > /home/hpcsmec15767/sfw/petsc/3.17.5/linux-debug/include/petscversion.h... no > checking /home/hpcsmec15767/sfw/petsc/3.17.5/include/petscversion.h > usability... no > checking /home/hpcsmec15767/sfw/petsc/3.17.5/include/petscversion.h > presence... no > checking for /home/hpcsmec15767/sfw/petsc/3.17.5/include/petscversion.h... > no > configure: error: *** PETSc was not found, but --enable-petsc-required was > specified. > > This one I am trying in the hpc cluster. Few months ago, I tried to > install this IBAMR-0.13.0 open software with petsc 3.17.5 and libmesh 1.6.2 > in our local machine, the same error occurred though. > Right now I am using IBAMR-0.11.0 with petsc 3.13.4 and libmesh 1.6.2 and > it is working in our local machine. > Does petsc 3.17.5 version compatible with libmesh 1.6.2? > The PETSc 3.17.x release series was started in March 2022 commit 30c35bf2dfad782abeabcf00da45fe2af1c737cf (tag: v3.17.0) > Author: Satish Balay <ba...@mc...> > Date: Wed Mar 30 20:50:56 2022 -0500 While libmesh 1.6.2 is from August 2021: commit e98f7419bd062d4c6b3cc3727899e892915af730 (tag: v1.6.2) > Author: John W. Peterson <jwp...@gm...> > Date: Mon Aug 2 14:59:29 2021 -0500 so it predates PETSc 3.17 by several months. Therefore it's definitely possible they are not compatible. Out of curiosity, where is petscversion.h actually located in your installation of PETSc, since it is not located in any of the places listed above? Also, how exactly do you install PETSc? If you follow the directions that are printed to the screen when building PETSc from source then the PETSc headers should just be located at $PETSC_DIR/include and $PETSC_ARCH is not needed/used by libmesh configure. -- John |
From: INTURU S. 2. <int...@vi...> - 2023-09-01 06:26:02
|
Hi John, I tried with PETSC_DIR=/home/hpcsmec15767/sfw/petsc/3.17.5. I got the same error as mentioned below checking for built-in XDR support... yes checking /home/hpcsmec15767/sfw/petsc/3.17.5/linux-debug/include/petscversion.h usability... no checking /home/hpcsmec15767/sfw/petsc/3.17.5/linux-debug/include/petscversion.h presence... no checking for /home/hpcsmec15767/sfw/petsc/3.17.5/linux-debug/include/petscversion.h... no checking /home/hpcsmec15767/sfw/petsc/3.17.5/include/petscversion.h usability... no checking /home/hpcsmec15767/sfw/petsc/3.17.5/include/petscversion.h presence... no checking for /home/hpcsmec15767/sfw/petsc/3.17.5/include/petscversion.h... no configure: error: *** PETSc was not found, but --enable-petsc-required was specified. This one I am trying in the hpc cluster. Few months ago, I tried to install this IBAMR-0.13.0 open software with petsc 3.17.5 and libmesh 1.6.2 in our local machine, the same error occurred though. Right now I am using IBAMR-0.11.0 with petsc 3.13.4 and libmesh 1.6.2 and it is working in our local machine. Does petsc 3.17.5 version compatible with libmesh 1.6.2? I am sharing the config.log file. Please find the attachment and do the needful. Thanks and regards Srinivas On Fri, Sep 1, 2023 at 12:43 AM John Peterson <jwp...@gm...> wrote: > Unfortunately, there is no additional information in the log file beyond > > configure:4977: result: <<< Could not find a viable PETSc Makefile to >> determine PETSC_CC_INCLUDES, etc. >>> > > > which means that your PETSc installation is not how we expected it to be. > Based on the args you passed to configure, I see that you set the following > > PETSC_DIR=/home/hpcsmec15767/sfw/petsc/3.17.5/linux-debug > PETSC_ARCH=linux-debug > > In this case we expect to find the following two files: > ${PETSC_DIR}/makefile > ${PETSC_DIR}/${PETSC_ARCH}/lib/petsc/conf/variables > > or the single file: > > ${PETSC_DIR}/lib/petsc/conf/variables > > Therefore, I think the issue is that your PETSC_DIR variable already > includes the PETSC_ARCH in it? I would try again setting > > PETSC_DIR=/home/hpcsmec15767/sfw/petsc/3.17.5 > > instead. > > -- > John > -- **Disclaimer:* This message was sent from Vellore Institute of Technology. The contents of this email may contain legally protected confidential or privileged information of “Vellore Institute of Technology”. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. If you have received this email in error, please promptly notify the sender by reply email and delete the original email and any backup copies without reading them.* |
From: John P. <jwp...@gm...> - 2023-08-31 19:13:46
|
Unfortunately, there is no additional information in the log file beyond configure:4977: result: <<< Could not find a viable PETSc Makefile to > determine PETSC_CC_INCLUDES, etc. >>> which means that your PETSc installation is not how we expected it to be. Based on the args you passed to configure, I see that you set the following PETSC_DIR=/home/hpcsmec15767/sfw/petsc/3.17.5/linux-debug PETSC_ARCH=linux-debug In this case we expect to find the following two files: ${PETSC_DIR}/makefile ${PETSC_DIR}/${PETSC_ARCH}/lib/petsc/conf/variables or the single file: ${PETSC_DIR}/lib/petsc/conf/variables Therefore, I think the issue is that your PETSC_DIR variable already includes the PETSC_ARCH in it? I would try again setting PETSC_DIR=/home/hpcsmec15767/sfw/petsc/3.17.5 instead. -- John |
From: INTURU S. 2. <int...@vi...> - 2023-08-31 15:43:52
|
Sorry for the mistake. Please find the attached file. On Thu, Aug 31, 2023 at 7:58 PM John Peterson <jwp...@gm...> wrote: > Hi, > > The config.log that you sent this time does not seem to be related to the > previous one, but rather to a MOOSE build? And the version of PETSc is > totally different from the previous log, it is now PETSc 3.11.4. > > In any event, the relevant configure output is: > > configure:34458: checking for >> /opt/moose/petsc-3.11.4/mpich-3.3_gcc-9.2.0-opt//include/petscversion.h >> configure:34458: result: yes >> configure:34525: result: <<< Found PETSc 3.11.4 installation in >> /opt/moose/petsc-3.11.4/mpich-3.3_gcc-9.2.0-opt ... >>> >> configure:34535: checking whether we can compile a trivial PETSc program >> configure:34564: mpicxx -c -std=gnu++11 >> -I/opt/moose/petsc-3.11.4/mpich-3.3_gcc-9.2.0-opt/include >> -I/opt/moose/petsc-3.11.4/mpich-3.3_gcc-9.2.0-opt//include >> -I/opt/moose/petsc-3.11.4/mpich-3.3_gcc-9.2.0-opt/include >> -I/opt/moose/petsc-3.11.4/mpich-3.3_gcc-9.2.0-opt/include conftest.cpp >&5 >> In file included from >> /opt/moose/petsc-3.11.4/mpich-3.3_gcc-9.2.0-opt/include/petscsys.h:14:0, >> from >> /opt/moose/petsc-3.11.4/mpich-3.3_gcc-9.2.0-opt/include/petscbag.h:4, >> from >> /opt/moose/petsc-3.11.4/mpich-3.3_gcc-9.2.0-opt/include/petsc.h:5, >> from conftest.cpp:144: >> /opt/moose/petsc-3.11.4/mpich-3.3_gcc-9.2.0-opt/include/petscconf.h:85:36: >> error: expected '}' before '__attribute' >> #define PETSC_DEPRECATED_ENUM(why) __attribute((deprecated)) >> ^ >> /opt/moose/petsc-3.11.4/mpich-3.3_gcc-9.2.0-opt/include/petscksp.h:430:76: >> note: in expansion of macro 'PETSC_DEPRECATED_ENUM' >> #define KSP_DIVERGED_PCSETUP_FAILED_DEPRECATED >> KSP_DIVERGED_PCSETUP_FAILED PETSC_DEPRECATED_ENUM("Use >> KSP_DIVERGED_PC_FAILED (since v3.11)") >> >> ^ >> /opt/moose/petsc-3.11.4/mpich-3.3_gcc-9.2.0-opt/include/petscksp.h:452:15: >> note: in expansion of macro 'KSP_DIVERGED_PCSETUP_FAILED_DEPRECATED' >> KSP_DIVERGED_PCSETUP_FAILED_DEPRECATED = -11, >> ^ >> In file included from >> /opt/moose/petsc-3.11.4/mpich-3.3_gcc-9.2.0-opt/include/petscsnes.h:6:0, >> from >> /opt/moose/petsc-3.11.4/mpich-3.3_gcc-9.2.0-opt/include/petscts.h:7, >> from >> /opt/moose/petsc-3.11.4/mpich-3.3_gcc-9.2.0-opt/include/petsc.h:29, >> from conftest.cpp:144: >> /opt/moose/petsc-3.11.4/mpich-3.3_gcc-9.2.0-opt/include/petscksp.h:452:55: >> error: expected unqualified-id before '=' token >> KSP_DIVERGED_PCSETUP_FAILED_DEPRECATED = -11, >> ^ >> /opt/moose/petsc-3.11.4/mpich-3.3_gcc-9.2.0-opt/include/petscksp.h:454:52: >> error: expected declaration before '}' token >> KSP_CONVERGED_ITERATING = 0} KSPConvergedReason; >> ^ > > > So there is a syntax error related to the __attribute keyword that appears > in one of the PETSc header files. This means that the compiler you are > using: > > configure:5255: mpicc --version >&5 >> gcc (Homebrew GCC 5.5.0_7) 5.5.0 > > > > is also different from the one in your previous email, and is apparently > too old to be able to compile the version of PETSc you are using. Note that > PETSc 3.11.4 is from March 2019 while GCC 5.5 is from 2017, so this could > explain the discrepancy. These types of errors are pretty common when > trying to build old versions of software from source on newer (looks like > you are using Ubuntu 18.04) machines, so I would recommend using > contemporary versions of all software. > > -- > John > -- **Disclaimer:* This message was sent from Vellore Institute of Technology. The contents of this email may contain legally protected confidential or privileged information of “Vellore Institute of Technology”. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. If you have received this email in error, please promptly notify the sender by reply email and delete the original email and any backup copies without reading them.* |
From: John P. <jwp...@gm...> - 2023-08-31 14:28:40
|
Hi, The config.log that you sent this time does not seem to be related to the previous one, but rather to a MOOSE build? And the version of PETSc is totally different from the previous log, it is now PETSc 3.11.4. In any event, the relevant configure output is: configure:34458: checking for > /opt/moose/petsc-3.11.4/mpich-3.3_gcc-9.2.0-opt//include/petscversion.h > configure:34458: result: yes > configure:34525: result: <<< Found PETSc 3.11.4 installation in > /opt/moose/petsc-3.11.4/mpich-3.3_gcc-9.2.0-opt ... >>> > configure:34535: checking whether we can compile a trivial PETSc program > configure:34564: mpicxx -c -std=gnu++11 > -I/opt/moose/petsc-3.11.4/mpich-3.3_gcc-9.2.0-opt/include > -I/opt/moose/petsc-3.11.4/mpich-3.3_gcc-9.2.0-opt//include > -I/opt/moose/petsc-3.11.4/mpich-3.3_gcc-9.2.0-opt/include > -I/opt/moose/petsc-3.11.4/mpich-3.3_gcc-9.2.0-opt/include conftest.cpp >&5 > In file included from > /opt/moose/petsc-3.11.4/mpich-3.3_gcc-9.2.0-opt/include/petscsys.h:14:0, > from > /opt/moose/petsc-3.11.4/mpich-3.3_gcc-9.2.0-opt/include/petscbag.h:4, > from > /opt/moose/petsc-3.11.4/mpich-3.3_gcc-9.2.0-opt/include/petsc.h:5, > from conftest.cpp:144: > /opt/moose/petsc-3.11.4/mpich-3.3_gcc-9.2.0-opt/include/petscconf.h:85:36: > error: expected '}' before '__attribute' > #define PETSC_DEPRECATED_ENUM(why) __attribute((deprecated)) > ^ > /opt/moose/petsc-3.11.4/mpich-3.3_gcc-9.2.0-opt/include/petscksp.h:430:76: > note: in expansion of macro 'PETSC_DEPRECATED_ENUM' > #define KSP_DIVERGED_PCSETUP_FAILED_DEPRECATED > KSP_DIVERGED_PCSETUP_FAILED PETSC_DEPRECATED_ENUM("Use > KSP_DIVERGED_PC_FAILED (since v3.11)") > > ^ > /opt/moose/petsc-3.11.4/mpich-3.3_gcc-9.2.0-opt/include/petscksp.h:452:15: > note: in expansion of macro 'KSP_DIVERGED_PCSETUP_FAILED_DEPRECATED' > KSP_DIVERGED_PCSETUP_FAILED_DEPRECATED = -11, > ^ > In file included from > /opt/moose/petsc-3.11.4/mpich-3.3_gcc-9.2.0-opt/include/petscsnes.h:6:0, > from > /opt/moose/petsc-3.11.4/mpich-3.3_gcc-9.2.0-opt/include/petscts.h:7, > from > /opt/moose/petsc-3.11.4/mpich-3.3_gcc-9.2.0-opt/include/petsc.h:29, > from conftest.cpp:144: > /opt/moose/petsc-3.11.4/mpich-3.3_gcc-9.2.0-opt/include/petscksp.h:452:55: > error: expected unqualified-id before '=' token > KSP_DIVERGED_PCSETUP_FAILED_DEPRECATED = -11, > ^ > /opt/moose/petsc-3.11.4/mpich-3.3_gcc-9.2.0-opt/include/petscksp.h:454:52: > error: expected declaration before '}' token > KSP_CONVERGED_ITERATING = 0} KSPConvergedReason; > ^ So there is a syntax error related to the __attribute keyword that appears in one of the PETSc header files. This means that the compiler you are using: configure:5255: mpicc --version >&5 > gcc (Homebrew GCC 5.5.0_7) 5.5.0 is also different from the one in your previous email, and is apparently too old to be able to compile the version of PETSc you are using. Note that PETSc 3.11.4 is from March 2019 while GCC 5.5 is from 2017, so this could explain the discrepancy. These types of errors are pretty common when trying to build old versions of software from source on newer (looks like you are using Ubuntu 18.04) machines, so I would recommend using contemporary versions of all software. -- John |
From: INTURU S. 2. <int...@vi...> - 2023-08-31 03:50:14
|
Hi John, IBAMR open software recommended libmesh 1.6.2. I sent a config.log file in the first email and this is from the libmesh directory. Is this the file you need? I am sending it again. Please find the attachment Thanks and regards Srinivas On Thu, Aug 31, 2023, 01:56 John Peterson <jwp...@gm...> wrote: > Hi, > > Is there a particular reason that you are trying to use libmesh 1.6.2? > It's about two years old at this point, and there have been many updates > and improvements (including a stable release) since that time, so you will > probably have the most success if you use a more up-to-date version. > > The log you attached is the output of configure to the terminal, so it > doesn't really give much information other than: > <<< Could not find a viable PETSc Makefile to determine PETSC_CC_INCLUDES, > etc. >>> > > You might be able to get more detailed info about the failure to find > PETSc by looking at the config.log file generated by configure. > > -- > John > > > On Wed, Aug 30, 2023 at 5:49 AM INTURU SRINIVAS 20PHD0548 via > Libmesh-users <lib...@li...> wrote: > >> In continuation to the previous mail, I am sending the tasks done while >> configuring libmesh 1.6.2. The error is mentioned in this file. Please >> find >> the attached file and do the needful. > > -- **Disclaimer:* This message was sent from Vellore Institute of Technology. The contents of this email may contain legally protected confidential or privileged information of “Vellore Institute of Technology”. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. If you have received this email in error, please promptly notify the sender by reply email and delete the original email and any backup copies without reading them.* |
From: John P. <jwp...@gm...> - 2023-08-30 20:26:22
|
Hi, Is there a particular reason that you are trying to use libmesh 1.6.2? It's about two years old at this point, and there have been many updates and improvements (including a stable release) since that time, so you will probably have the most success if you use a more up-to-date version. The log you attached is the output of configure to the terminal, so it doesn't really give much information other than: <<< Could not find a viable PETSc Makefile to determine PETSC_CC_INCLUDES, etc. >>> You might be able to get more detailed info about the failure to find PETSc by looking at the config.log file generated by configure. -- John On Wed, Aug 30, 2023 at 5:49 AM INTURU SRINIVAS 20PHD0548 via Libmesh-users <lib...@li...> wrote: > In continuation to the previous mail, I am sending the tasks done while > configuring libmesh 1.6.2. The error is mentioned in this file. Please find > the attached file and do the needful. |
From: INTURU S. 2. <int...@vi...> - 2023-08-30 10:49:11
|
In continuation to the previous mail, I am sending the tasks done while configuring libmesh 1.6.2. The error is mentioned in this file. Please find the attached file and do the needful. Thanks and Regards Srinivas On Wed, Aug 30, 2023 at 1:47 PM INTURU SRINIVAS 20PHD0548 < int...@vi...> wrote: > Hello, > > I am building IBAMR open software as given in the link > https://ibamr.github.io/. When I configured libmesh, I got the error > mentioning "petsc was not found". I am sharing the config.log file. Please > find the attachment and do the needful. > > > Thanks and Regards > Srinivas > -- **Disclaimer:* This message was sent from Vellore Institute of Technology. The contents of this email may contain legally protected confidential or privileged information of “Vellore Institute of Technology”. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. If you have received this email in error, please promptly notify the sender by reply email and delete the original email and any backup copies without reading them.* |
From: INTURU S. 2. <int...@vi...> - 2023-08-30 08:51:50
|
Hello, I am building IBAMR open software as given in the link https://ibamr.github.io/. When I configured libmesh, I got the error mentioning "petsc was not found". I am sharing the config.log file. Please find the attachment and do the needful. Thanks and Regards Srinivas -- **Disclaimer:* This message was sent from Vellore Institute of Technology. The contents of this email may contain legally protected confidential or privileged information of “Vellore Institute of Technology”. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. If you have received this email in error, please promptly notify the sender by reply email and delete the original email and any backup copies without reading them.* |
From: John P. <jwp...@gm...> - 2023-01-10 15:47:53
|
Hi, I would first verify that the System's solution vector has the expected values after calling "copy_elemental_solution". You could do this by just printing out the solution vector if it is a small enough problem. Once you are sure that part is working, I would have to assume that there is some kind of bug with System::point_value() in libmesh-1.5.1. Since that libmesh version is from 2019 ( https://github.com/libMesh/libmesh/wiki/libMesh-release-history), it's unlikely that anyone will be able to spend much time debugging it. If you find that we have the same bug in libmesh master or libmesh-1.7.1, someone might be able to take a closer look. Also, you may find that you get faster/more varied responses by starting a Discussion on GitHub (https://github.com/libMesh/libmesh/discussions) than by using this old mailing list. -- John On Fri, Jan 6, 2023 at 4:18 PM Laryssa Abdala <la....@gm...> wrote: > Hello, > > I've been having trouble evaluating a cell-centered field (stored in a > ExplicitSystem) at a point using *Number libMesh::System::point_value ( > unsigned int var, const Point & p, const Elem * e). *More specifically, I > want to evaluate the field at the centroid of the elements. For most > points/elements, *libMesh::System::point_value* returns zero, but for some > elements it returns the expected non-zero value. Please see the toy example > below. > > Does anyone have suggestions on how to deal with this? > > Libmesh version: 1.5.1 > > Thanks, > Laryssa > > This is a toy example: > #include "libmesh/exodusII_io.h" > #include "libmesh/mesh.h" > #include "libmesh/elem.h" > #include "libmesh/mesh_base.h" > #include "libmesh/explicit_system.h" > #include "libmesh/equation_systems.h" > #include "libmesh/dof_map.h" > int main(int argc, char ** argv) > { > using namespace libMesh; > LibMeshInit init(argc, argv, MPI_COMM_WORLD); > Mesh mesh_fiber(init.comm()); > ExodusII_IO importer(mesh_fiber); > importer.read("file.e"); > mesh_fiber.prepare_for_use(); > > libMesh::EquationSystems es_fiber(mesh_fiber); > typedef libMesh::ExplicitSystem FiberSystem; > FiberSystem& fiber_system = es_fiber.add_system<FiberSystem>("fibers"); > fiber_system.add_variable("fibersX", libMesh::CONSTANT, libMesh > ::MONOMIAL); > fiber_system.add_variable("fibersY", libMesh::CONSTANT, libMesh > ::MONOMIAL); > fiber_system.add_variable("fibersZ", libMesh::CONSTANT, libMesh > ::MONOMIAL); > fiber_system.init(); > > unsigned int step=1; > > //Read fiber data into mesh_fiber > importer.copy_elemental_solution(fiber_system, "fibersX", "fibersX", > step); > importer.copy_elemental_solution(fiber_system, "fibersY", "fibersY", > step); > importer.copy_elemental_solution(fiber_system, "fibersZ", "fibersZ", > step); > fiber_system.print_info(); > > libMesh::MeshBase::const_element_iterator el = mesh_fiber. > active_local_elements_begin(); > const libMesh::MeshBase::const_element_iterator end_el = mesh_fiber. > active_local_elements_end(); > > std::vector<libMesh::Number> ff(3); > for (; el != end_el; ++el) > { > Elem * elem= *el; > libMesh::Point centroid = elem->centroid(); > > ff[0] = fiber_system.point_value(fiber_system.variable_number( > "fibersX"), centroid, *elem); > ff[1] = fiber_system.point_value(fiber_system.variable_number( > "fibersY"), centroid, *elem); > ff[2] = fiber_system.point_value(fiber_system.variable_number( > "fibersZ"), centroid, *elem); > std::cout << "ff = (" << ff[0] << ", " << ff[1] << ", " << ff[2] > <<") > , norm=" << std::sqrt(ff[0]*ff[0]+ff[1]*ff[1]+ff[2]*ff[2]) << std::endl; > > } > > return 0; > } > |
From: Laryssa A. <la....@gm...> - 2023-01-06 22:18:14
|
Hello, I've been having trouble evaluating a cell-centered field (stored in a ExplicitSystem) at a point using *Number libMesh::System::point_value ( unsigned int var, const Point & p, const Elem * e). *More specifically, I want to evaluate the field at the centroid of the elements. For most points/elements, *libMesh::System::point_value* returns zero, but for some elements it returns the expected non-zero value. Please see the toy example below. Does anyone have suggestions on how to deal with this? Libmesh version: 1.5.1 Thanks, Laryssa This is a toy example: #include "libmesh/exodusII_io.h" #include "libmesh/mesh.h" #include "libmesh/elem.h" #include "libmesh/mesh_base.h" #include "libmesh/explicit_system.h" #include "libmesh/equation_systems.h" #include "libmesh/dof_map.h" int main(int argc, char ** argv) { using namespace libMesh; LibMeshInit init(argc, argv, MPI_COMM_WORLD); Mesh mesh_fiber(init.comm()); ExodusII_IO importer(mesh_fiber); importer.read("file.e"); mesh_fiber.prepare_for_use(); libMesh::EquationSystems es_fiber(mesh_fiber); typedef libMesh::ExplicitSystem FiberSystem; FiberSystem& fiber_system = es_fiber.add_system<FiberSystem>("fibers"); fiber_system.add_variable("fibersX", libMesh::CONSTANT, libMesh ::MONOMIAL); fiber_system.add_variable("fibersY", libMesh::CONSTANT, libMesh ::MONOMIAL); fiber_system.add_variable("fibersZ", libMesh::CONSTANT, libMesh ::MONOMIAL); fiber_system.init(); unsigned int step=1; //Read fiber data into mesh_fiber importer.copy_elemental_solution(fiber_system, "fibersX", "fibersX", step); importer.copy_elemental_solution(fiber_system, "fibersY", "fibersY", step); importer.copy_elemental_solution(fiber_system, "fibersZ", "fibersZ", step); fiber_system.print_info(); libMesh::MeshBase::const_element_iterator el = mesh_fiber. active_local_elements_begin(); const libMesh::MeshBase::const_element_iterator end_el = mesh_fiber. active_local_elements_end(); std::vector<libMesh::Number> ff(3); for (; el != end_el; ++el) { Elem * elem= *el; libMesh::Point centroid = elem->centroid(); ff[0] = fiber_system.point_value(fiber_system.variable_number( "fibersX"), centroid, *elem); ff[1] = fiber_system.point_value(fiber_system.variable_number( "fibersY"), centroid, *elem); ff[2] = fiber_system.point_value(fiber_system.variable_number( "fibersZ"), centroid, *elem); std::cout << "ff = (" << ff[0] << ", " << ff[1] << ", " << ff[2] <<") , norm=" << std::sqrt(ff[0]*ff[0]+ff[1]*ff[1]+ff[2]*ff[2]) << std::endl; } return 0; } |
From: John P. <jwp...@gm...> - 2022-10-28 18:32:30
|
Hello Omar, Unfortunately, this mailing list does not allow attachments, so I cannot see your config.log. You could create a discussion on the libmesh GitHub page and attach your config.log there, or find some other way to share it. There has been an issue reported with linking against VTK 9.2 https://github.com/libMesh/libmesh/pull/3346 so you may also have luck trying the approach proposed in that PR. -- John On Fri, Oct 28, 2022 at 12:17 PM omar.lopez <oma...@in...> wrote: > Hello all, > > I am trying to use libmesh with VTK, however I cannot build libmesh with > VTK, I attached the config.log file. > > I am using this configuration command: > > "../configure --prefix=/home/omar/libmesh/install\ --enable-distmesh\ > --with-vtk-include=/opt/vtk/9.2.2/include/vtk-9.2\ > --with-vtk-lib=/opt/vtk/9.2.2/lib/vtk-9.2\" > > I am using Ubuntu 22.04.1 LTS and VTK 9.2.2. > > I hope you can help me to find the error. > > Thank you very much in advance. > > Omar L. > -- John |
From: omar.lopez <oma...@in...> - 2022-10-28 17:16:54
|
Hello all, I am trying to use libmesh with VTK, however I cannot build libmesh with VTK, I attached the config.log file. I am using this configuration command: "../configure --prefix=/home/omar/libmesh/install\ --enable-distmesh\ --with-vtk-include=/opt/vtk/9.2.2/include/vtk-9.2\ --with-vtk-lib=/opt/vtk/9.2.2/lib/vtk-9.2\" I am using Ubuntu 22.04.1 LTS and VTK 9.2.2. I hope you can help me to find the error. Thank you very much in advance. Omar L. AVISO DE CONFIDENCIALIDAD: Este correo electrónico, incluyendo en su caso, los archivos adjuntos al mismo pueden contener información de carácter confidencial y/o privilegiada, y se envÃan a la atención única y exclusivamente de la persona y/o entidad a quien va dirigido. La copia, revisión, uso, revelación y/o distribución de dicha información confidencial sin la autorización por escrito del Instituto Nacional de AstrofÃsica, Ãptica y Electrónica (INAOE) está prohibida. Si usted no es el destinatario a quien se dirige el presente correo, favor de contactar al remitente respondiendo al presente correo y eliminar el correo original incluyendo sus archivos, asà como cualquiera copia de este. Mediante la recepción del presente correo usted reconoce y acepta que en caso de incumplimiento de su parte y/o de sus representantes a los términos antes mencionados, este Centro Público de Investigación tendrá el derecho de reclamar los daños y perjuicios que dicha vulneración le cause; asimismo se hace de su conocimiento que el Instituto Nacional de AstrofÃsica, Ãptica y Electrónica (INAOE) está obligado a salvaguardar los datos personales que le sean proporcionados por terceros, en los términos de la Ley General de Protección de Datos Personales en Posesión de Sujetos Obligados. AVISO DE PRIVACIDAD, En cumplimiento con la Ley General de Protección de Datos Personales en Posesión de Sujetos Obligados, al recibir datos de carácter personal a través de este medio, se entiende el consentimiento expreso del titular de los datos personales para utilizarlos en actividades propias del Instituto Nacional de AstrofÃsica, Ãptica y Electrónica (INAOE). Para mayor información, lo invitamos a consultar el Aviso de Privacidad en nuestro portal: https://www.inaoep.mx |
From: omar.lopez <oma...@in...> - 2022-10-28 15:42:28
|
Hello, Currently I am having problems to configure libmesh, since when I run example "introduction_ex3, I cannot see anything with VTK. In the line 2362 from config.log file it say: "configure:47211: result: <<< --enable-parmesh is deprecated; use --enable-distmesh >>>". I attached this file. I am using Ubuntu 22.04.1 LTS, and I want use libmesh with VTK. My configure command is the following: "../configure --prefix=/home/omar/libmesh/install\ --enable-distmesh\ --with-vtk-include=/opt/vtk/9.2.2/include/vtk-9.2\ --with-vtk-lib=/opt/vtk/9.2.2/lib/vtk-9.2\" Thank you very much in advanced. Omr López López AVISO DE CONFIDENCIALIDAD: Este correo electrónico, incluyendo en su caso, los archivos adjuntos al mismo pueden contener información de carácter confidencial y/o privilegiada, y se envían a la atención única y exclusivamente de la persona y/o entidad a quien va dirigido. La copia, revisión, uso, revelación y/o distribución de dicha información confidencial sin la autorización por escrito del Instituto Nacional de Astrofísica, Óptica y Electrónica (INAOE) está prohibida. Si usted no es el destinatario a quien se dirige el presente correo, favor de contactar al remitente respondiendo al presente correo y eliminar el correo original incluyendo sus archivos, así como cualquiera copia de este. Mediante la recepción del presente correo usted reconoce y acepta que en caso de incumplimiento de su parte y/o de sus representantes a los términos antes mencionados, este Centro Público de Investigación tendrá el derecho de reclamar los daños y perjuicios que dicha vulneración le cause; asimismo se hace de su conocimiento que el Instituto Nacional de Astrofísica, Óptica y Electrónica (INAOE) está obligado a salvaguardar los datos personales que le sean proporcionados por terceros, en los términos de la Ley General de Protección de Datos Personales en Posesión de Sujetos Obligados. AVISO DE PRIVACIDAD, En cumplimiento con la Ley General de Protección de Datos Personales en Posesión de Sujetos Obligados, al recibir datos de carácter personal a través de este medio, se entiende el consentimiento expreso del titular de los datos personales para utilizarlos en actividades propias del Instituto Nacional de Astrofísica, Óptica y Electrónica (INAOE). Para mayor información, lo invitamos a consultar el Aviso de Privacidad en nuestro portal: https://www.inaoep.mx |
From: Yu Z. <eli...@li...> - 2022-08-20 06:33:41
|
Hi, John, Thanks for your helpful suggestions. Having tested several cases, I found that the problem comes from assigning back the active side to the FEMContext c.side. Now things look good. Many thanks again for your quick response and helps! Best regards, Eli ________________________________ From: John Peterson <jwp...@gm...> Sent: Friday, August 19, 2022 12:26 AM To: Yu Zhong <eli...@li...> Cc: lib...@li... <lib...@li...> Subject: Re: [Libmesh-users] imposing boundary conditions inside the domain On Thu, Aug 18, 2022 at 5:20 AM Yu Zhong <eli...@li...<mailto:eli...@li...>> wrote: Dear all, For a 2D problem, I'm trying to impose Dirichlet BC on a physical boundary connecting two subdomains in a full domain (containing more than 2 subdomains). With the penalty method, I tried with c.has_side_boundary_id(ID) to find this physical boundary, where ID is the physical curve ID defined in gmsh. However, it does not work. This method seems only working with outer boundaries instead of those within the full domain. I went through the examples, and found the Miscellaneous Example 9 provides a solution for this issue, where two different meshes are created in two subdomains. Then the boundary connecting these two subdomains can be found as those outer boundaries for a single domain. This method would ask for heavy works on the mesh generation side when there are many such interior B.C. needed within the full domain. I just wonder whether libmesh has any routine that can automatically find the interior edges with specific IDs, such that specific B.C. can be imposed onto these edges. Hi, Libmesh has support for interior sides, so there is most likely some bug, either on our part of yours, that prevents this from working. Off the top of my head, I see that the has_side_boundary_id() function only works for the FEMContext's currently active side, bool FEMContext::has_side_boundary_id(boundary_id_type id) const { return _boundary_info.has_boundary_id(&(this->get_elem()), side, id); } so you definitely need to be sure that you are calling this function in a loop over all elem sides (and not just exterior boundary sides). Another possibility is that the Gmsh reader is not properly storing your internal sides, so one debugging idea would be to call BoundaryInfo::print_info() after reading in your Mesh, and just confirm that all the (elem, side, id) tuples that you expect to be present are actually present. You will most likely need to share either the real code or (preferably) a simplified example which demonstrates the error in order for us to debug the problem further. -- John |
From: John P. <jwp...@gm...> - 2022-08-18 16:27:00
|
On Thu, Aug 18, 2022 at 5:20 AM Yu Zhong <eli...@li...> wrote: > Dear all, > > For a 2D problem, I'm trying to impose Dirichlet BC on a physical boundary > connecting two subdomains in a full domain (containing more than 2 > subdomains). With the penalty method, I tried with > > c.has_side_boundary_id(ID) > > to find this physical boundary, where ID is the physical curve ID defined > in gmsh. However, it does not work. This method seems only working with > outer boundaries instead of those within the full domain. > > I went through the examples, and found the Miscellaneous Example 9 > provides a solution for this issue, where two different meshes are created > in two subdomains. Then the boundary connecting these two subdomains can be > found as those outer boundaries for a single domain. This method would ask > for heavy works on the mesh generation side when there are many such > interior B.C. needed within the full domain. > > I just wonder whether libmesh has any routine that can automatically find > the interior edges with specific IDs, such that specific B.C. can be > imposed onto these edges. > Hi, Libmesh has support for interior sides, so there is most likely some bug, either on our part of yours, that prevents this from working. Off the top of my head, I see that the has_side_boundary_id() function only works for the FEMContext's currently active side, bool FEMContext::has_side_boundary_id(boundary_id_type id) const { return _boundary_info.has_boundary_id(&(this->get_elem()), side, id); } so you definitely need to be sure that you are calling this function in a loop over all elem sides (and not just exterior boundary sides). Another possibility is that the Gmsh reader is not properly storing your internal sides, so one debugging idea would be to call BoundaryInfo::print_info() after reading in your Mesh, and just confirm that all the (elem, side, id) tuples that you expect to be present are actually present. You will most likely need to share either the real code or (preferably) a simplified example which demonstrates the error in order for us to debug the problem further. -- John |
From: Yu Z. <eli...@li...> - 2022-08-18 10:20:13
|
Dear all, For a 2D problem, I'm trying to impose Dirichlet BC on a physical boundary connecting two subdomains in a full domain (containing more than 2 subdomains). With the penalty method, I tried with c.has_side_boundary_id(ID) to find this physical boundary, where ID is the physical curve ID defined in gmsh. However, it does not work. This method seems only working with outer boundaries instead of those within the full domain. I went through the examples, and found the Miscellaneous Example 9 provides a solution for this issue, where two different meshes are created in two subdomains. Then the boundary connecting these two subdomains can be found as those outer boundaries for a single domain. This method would ask for heavy works on the mesh generation side when there are many such interior B.C. needed within the full domain. I just wonder whether libmesh has any routine that can automatically find the interior edges with specific IDs, such that specific B.C. can be imposed onto these edges. Thank you very much. Best regards, Eli |
From: David K. <dav...@ak...> - 2022-04-28 14:54:11
|
Hi, Thanks for your comments. I don't know the answers here. The SCM is needed in order to get rigorous error bounds, but as you see here it is complicated and can be computationally intensive, so a lot of people just skip it. In order to get to the bottom of your issues, you'd have to investigate more deeply what is happening to cause these issues (e.g. print out a lot of information from what is happening as you run the SCM), and see if you can diagnose the issue and improve it. So I'm afraid I don't have much other advice here, other than these kinds of difficulties are quite common with SCM in my experience, which is why people often skip it. Regards, David On Thu, Apr 28, 2022 at 9:51 AM 강다영 <dyd...@pu...> wrote: > Dear all, > > Hi, > I have a question about the error bound estimated by SCM in libmesh. > > My model has three parameters, four subdomains with no geometric > parameterization, and a DOF near 20,000. > I did SCM training with this model and checked that the output error bound > somehow gave a negative value at some parameters. > However, I believe it is not plausible to have a "negative" value for the > error bound because the bound may stem from the norm value. > > At first, I used 1000 SCM samples, and SCM gave a negative error bound even > at the reference parameter. > Then I tried more samples, i.e., 3000. In this case, the error bound at the > reference parameter was all positive. But still, it was negative at some > parameters like maximum and minimum parameters. > > Apparently, it seems like more samples decrease the cases that give minus > error bound. But the problem is that the SCM training takes too much time. > For 3000 samples, it took nearly five days only for SCM training. Now I'm > trying with 6000 samples, and I guess it will take much more time. > > I hope more samples will solve the negative bound problem anyway, but I > still wonder how it is possible to have a minus value for the error bound. > Could you give me some information to avoid this problem? > > Furthermore, is there any rule of thumb for the number of SCM samples? > For now, I'm just randomly increasing the number of samples. > > I'd be very much grateful if someone could give me any comments on this. > > Best regards, > Dayoung Kang > > _______________________________________________ > Libmesh-users mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-users > |
From: 강다영 <dyd...@pu...> - 2022-04-28 13:51:14
|
Dear all, Hi, I have a question about the error bound estimated by SCM in libmesh. My model has three parameters, four subdomains with no geometric parameterization, and a DOF near 20,000. I did SCM training with this model and checked that the output error bound somehow gave a negative value at some parameters. However, I believe it is not plausible to have a "negative" value for the error bound because the bound may stem from the norm value. At first, I used 1000 SCM samples, and SCM gave a negative error bound even at the reference parameter. Then I tried more samples, i.e., 3000. In this case, the error bound at the reference parameter was all positive. But still, it was negative at some parameters like maximum and minimum parameters. Apparently, it seems like more samples decrease the cases that give minus error bound. But the problem is that the SCM training takes too much time. For 3000 samples, it took nearly five days only for SCM training. Now I'm trying with 6000 samples, and I guess it will take much more time. I hope more samples will solve the negative bound problem anyway, but I still wonder how it is possible to have a minus value for the error bound. Could you give me some information to avoid this problem? Furthermore, is there any rule of thumb for the number of SCM samples? For now, I'm just randomly increasing the number of samples. I'd be very much grateful if someone could give me any comments on this. Best regards, Dayoung Kang |
From: David K. <dav...@ak...> - 2022-04-12 15:30:14
|
One extra comment from me is that I think you and John diagnosed the initial issue correctly, it is that you are using LAPACK for the SCM eigenproblems, and that uses dense matrices. As a result it doesn't scale well to larger problems. I recall that I set LAPACK as the default for SCM because I had a lot of trouble getting convergence with sparse eigensolvers like SLEPc for this case, I think the SCM eigenproblem is a difficult one to get convergence for. But I think the "real" fix here would be to get SLEPc to converge well, but I think that may not be easy to do (at least I wasn't able to do it reliably when I worked on this originally). Best, David On Tue, Apr 12, 2022 at 10:25 AM John Peterson <jwp...@gm...> wrote: > > > On Tue, Apr 12, 2022 at 8:47 AM 강다영 <dyd...@pu...> wrote: > >> Hello, >> Thank you for all your information and suggestions. >> >> You're right that I was using a LAPACK-based solver. >> As you recommended, I first tried to use another solver other than >> LAPACK, and I ended up with a convergence error in SCM. >> >> So second, I performed a mesh convergence study to see if further >> reduction in the DOF (degree of freedom) is possible. >> As a result, I can get a model with a DOF of 36426, far less than the >> maximum DOF available in LAPACK (46340). >> By this, I finally avoided the overflow error. >> >> But the thing is, the new error occurred, and the error message is >> ambiguous this time. >> The exact error message is: >> killed >> > > Depending on your OS, you may be able to figure out exactly why the > process was killed, but my guess is that you are now exceeding the > available memory on your system. For 36426 DOFs, you are trying to > construct a single array of approximately > > echo "36426 * 36426 * 8 / 1024^3" | bc -l > 9.88582876324653625488 > > Gigabytes in size, assuming double precision floating point values. Note > that, even if you have more RAM than this available on your system, it is > possible that there is no "contiguous" chunk of memory of this size > available, which is required when allocating arrays. > > -- > John > |
From: John P. <jwp...@gm...> - 2022-04-12 14:25:44
|
On Tue, Apr 12, 2022 at 8:47 AM 강다영 <dyd...@pu...> wrote: > Hello, > Thank you for all your information and suggestions. > > You're right that I was using a LAPACK-based solver. > As you recommended, I first tried to use another solver other than LAPACK, > and I ended up with a convergence error in SCM. > > So second, I performed a mesh convergence study to see if further > reduction in the DOF (degree of freedom) is possible. > As a result, I can get a model with a DOF of 36426, far less than the > maximum DOF available in LAPACK (46340). > By this, I finally avoided the overflow error. > > But the thing is, the new error occurred, and the error message is > ambiguous this time. > The exact error message is: > killed > Depending on your OS, you may be able to figure out exactly why the process was killed, but my guess is that you are now exceeding the available memory on your system. For 36426 DOFs, you are trying to construct a single array of approximately echo "36426 * 36426 * 8 / 1024^3" | bc -l 9.88582876324653625488 Gigabytes in size, assuming double precision floating point values. Note that, even if you have more RAM than this available on your system, it is possible that there is no "contiguous" chunk of memory of this size available, which is required when allocating arrays. -- John |
From: 강다영 <dyd...@pu...> - 2022-04-12 14:18:59
|
Hello, Thank you for all your information and suggestions. You're right that I was using a LAPACK-based solver. As you recommended, I first tried to use another solver other than LAPACK, and I ended up with a convergence error in SCM. So second, I performed a mesh convergence study to see if further reduction in the DOF (degree of freedom) is possible. As a result, I can get a model with a DOF of 36426, far less than the maximum DOF available in LAPACK (46340). By this, I finally avoided the overflow error. But the thing is, the new error occurred, and the error message is ambiguous this time. The exact error message is: killed Inspecting this, I found out that the further reduction of a DOF will not cause the error. But I'd want to know if there is another way to fix this error other than reducing the number of DOF. Could you possibly give me further advice on this? Thank you, all. Best regards, Dayoung Kang 2022년 4월 8일 (금) 오후 11:11, John Peterson <jwp...@gm...>님이 작성: > > > On Fri, Apr 8, 2022 at 8:25 AM 강다영 <dyd...@pu...> wrote: > >> Dear all, >> >> I have a question about the overflow error I met during the SCM training >> in >> Libmesh. >> >> For the training, I used the mesh model with a degree of freedom of >> 318,021. >> And I got an error message as below: >> >> [0]PETSC ERROR: --------------------- Error Message >> -------------------------------------------------------------- >> [0]PETSC ERROR: No support for this operation for this object type >> [0]PETSC ERROR: Product of two integer 317065 317065 overflow, you must >> ./configure PETSc with --with-64-bit-indices for the case you are running >> [0]PETSC ERROR: See https://www.mcs.anl.gov/petsc/documentation/faq.html >> for trouble shooting. >> [0]PETSC ERROR: Petsc Release Version 3.12.2, unknown >> [0]PETSC ERROR: example-opt on a arch-linux2-c-debug named >> X570-AORUS-ELITE >> by dc308-ubuntu Thu Apr 7 12:46:34 2022 >> [0]PETSC ERROR: Configure options --with-cc=mpicc --with-cxx=mpicxx >> --with-fc=mpif90 --download-fblaslapack --download-parmetis >> --download-metis --download-scalapack --download-hdf5 --download-superlu >> --download-mumps >> [0]PETSC ERROR: #1 PetscIntMultError() line 2167 in >> /home/dc308-ubuntu/Packages/petsc/include/petscsys.h >> [0]PETSC ERROR: #2 BVCreate_Svec() line 461 in >> /home/dc308-ubuntu/Packages/slepc/src/sys/classes/bv/impls/svec/svec.c >> [0]PETSC ERROR: #3 BVSetSizesFromVec() line 186 in >> /home/dc308-ubuntu/Packages/slepc/src/sys/classes/bv/interface/bvbasic.c >> [0]PETSC ERROR: #4 EPSAllocateSolution() line 570 in >> /home/dc308-ubuntu/Packages/slepc/src/eps/interface/epssetup.c >> [0]PETSC ERROR: #5 EPSSetUp_LAPACK() line 36 in >> /home/dc308-ubuntu/Packages/slepc/src/eps/impls/lapack/lapack.c >> [0]PETSC ERROR: #6 EPSSetUp() line 173 in >> /home/dc308-ubuntu/Packages/slepc/src/eps/interface/epssetup.c >> [0]PETSC ERROR: #7 EPSSolve() line 136 in >> /home/dc308-ubuntu/Packages/slepc/src/eps/interface/epssolve.c >> >> In the 3rd line of the error message, I noticed that the number "317065" >> matches with (the number of degree of freedom of model - the number of >> constrained degree of freedom of the model). >> Therefore, I decreased the degree of freedom to 7,503 to deal with this >> error. >> With this model, it was possible to finish the SCM training without an >> error. >> So I guess a large degree of freedom caused this overflow error. >> >> However, I'd still like to fix this overflow error to use the original >> model with a degree of freedom of 318,021 (for more accurate solutions). >> >> Could you possibly give some information on how to finish SCM training for >> a model with a large degree of freedom without the overflow error? >> And I'd appreciate it if you could let me know the maximum degree of >> freedom that will not cause the overflow error. >> > > Hi Dayoung, > > I'm speculating here, but it looks like you are using a LAPACK-based > (hence dense) solver, so that will limit the size of problem that you can > solve. This solver apparently needs to build a single array of size > NDOFS**2, so the largest size problem you will be able to run is likely > approximately NODFS = sqrt(INT_MAX) = sqrt(2147483647) = 46340. I don't > know exactly how to fix this issue, but it would probably involve using a > different solver at the very least. Finally, our mailing list is not really > followed by many people, so you may also have more luck by starting a > GitHub Discussion (https://github.com/libMesh/libmesh/discussions) on > this topic. > > -- > John > |
From: David K. <dav...@ak...> - 2022-04-08 14:24:43
|
Hello, I don't think there is an easy fix for an "overflow" issue like this. The first step would be to check why we need the "Product of two integer 317065 317065" for the SCM case, and to see if there is a way to avoid that. Unfortunately I don't have time to look into this myself, though. Could you run in debug mode and identify which part of the code is triggering this error and then perhaps I can give further advice based on that? Best regards, David On Fri, Apr 8, 2022 at 9:24 AM 강다영 <dyd...@pu...> wrote: > Dear all, > > I have a question about the overflow error I met during the SCM training in > Libmesh. > > For the training, I used the mesh model with a degree of freedom of > 318,021. > And I got an error message as below: > > [0]PETSC ERROR: --------------------- Error Message > -------------------------------------------------------------- > [0]PETSC ERROR: No support for this operation for this object type > [0]PETSC ERROR: Product of two integer 317065 317065 overflow, you must > ./configure PETSc with --with-64-bit-indices for the case you are running > [0]PETSC ERROR: See https://www.mcs.anl.gov/petsc/documentation/faq.html > for trouble shooting. > [0]PETSC ERROR: Petsc Release Version 3.12.2, unknown > [0]PETSC ERROR: example-opt on a arch-linux2-c-debug named X570-AORUS-ELITE > by dc308-ubuntu Thu Apr 7 12:46:34 2022 > [0]PETSC ERROR: Configure options --with-cc=mpicc --with-cxx=mpicxx > --with-fc=mpif90 --download-fblaslapack --download-parmetis > --download-metis --download-scalapack --download-hdf5 --download-superlu > --download-mumps > [0]PETSC ERROR: #1 PetscIntMultError() line 2167 in > /home/dc308-ubuntu/Packages/petsc/include/petscsys.h > [0]PETSC ERROR: #2 BVCreate_Svec() line 461 in > /home/dc308-ubuntu/Packages/slepc/src/sys/classes/bv/impls/svec/svec.c > [0]PETSC ERROR: #3 BVSetSizesFromVec() line 186 in > /home/dc308-ubuntu/Packages/slepc/src/sys/classes/bv/interface/bvbasic.c > [0]PETSC ERROR: #4 EPSAllocateSolution() line 570 in > /home/dc308-ubuntu/Packages/slepc/src/eps/interface/epssetup.c > [0]PETSC ERROR: #5 EPSSetUp_LAPACK() line 36 in > /home/dc308-ubuntu/Packages/slepc/src/eps/impls/lapack/lapack.c > [0]PETSC ERROR: #6 EPSSetUp() line 173 in > /home/dc308-ubuntu/Packages/slepc/src/eps/interface/epssetup.c > [0]PETSC ERROR: #7 EPSSolve() line 136 in > /home/dc308-ubuntu/Packages/slepc/src/eps/interface/epssolve.c > > In the 3rd line of the error message, I noticed that the number "317065" > matches with (the number of degree of freedom of model - the number of > constrained degree of freedom of the model). > Therefore, I decreased the degree of freedom to 7,503 to deal with this > error. > With this model, it was possible to finish the SCM training without an > error. > So I guess a large degree of freedom caused this overflow error. > > However, I'd still like to fix this overflow error to use the original > model with a degree of freedom of 318,021 (for more accurate solutions). > > Could you possibly give some information on how to finish SCM training for > a model with a large degree of freedom without the overflow error? > And I'd appreciate it if you could let me know the maximum degree of > freedom that will not cause the overflow error. > > Thank you for your help. > > Best regards, > Dayoung Kang > > _______________________________________________ > Libmesh-users mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-users > |