libmesh-users — General information for libmesh users

Re: [Libmesh-users] make check Error: Solver is unknown.

[<ed...@op...>]

> Hmm... it seems to me that you should not hit exactly this error 
> because of
> this logic:
> 
>   // check that we have the required solver:
>   std::string solver;
>   solver = input.next(solver);
>   if (solver == "mumps")
>   {
> #ifndef LIBMESH_PETSC_HAVE_MUMPS
>     libmesh_example_requires(false, "PETSc compiled with MUMPS 
> support");
> #endif
>   }
>   else if (solver == "superlu")
>   {
> #ifndef LIBMESH_PETSC_HAVE_SUPERLU_DIST
>     libmesh_example_requires(false, "PETSc compiled with SuperLU 
> support");
> #endif
>   }
>   else
>   {
>      libMesh::err << "Error: Solver " << solver << " is unknown."
>                   << std::endl;
>      return 1;
>   }
> 
> i.e. you should hit the "libmesh_example_requires" in the first 
> if-block.
> But perhaps you are using an older version of libmesh which doesn't 
> have
> this check.
> 
> Either way, it's not fatal error with your libmesh build, just an 
> example
> that requires a specific solver that you don't have in your build of 
> PETSc.

Thank you for your answer, John. I am using v1.5.1 (as suggested on 
another e-mail). How do I set flags to configure with MUMPS? Does  
--enable-mumps  work? Thank you! Have nice holidays :) .

-------------------------------------------------
This free account was provided by VFEmail.net - report spam to ab...@vf...
 
ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  

Re: [Libmesh-users] make check Error: Solver is unknown.

[John P. <jwp...@gm...>]

On Sat, Dec 21, 2019 at 3:42 PM <ed...@op...> wrote:

> Hello,
>
> I am getting an error with `make check`. I can live with another
> compilation that I already have, but if you want the debugging
> information, let me know.
>
>
> ** Compilation set-up of PETSc and libmesh
>
> My compilation configuration can be seen here:
>
> - PETSc:
>    - https://notabug.org/broncodev/petsc-pkgbuild
>      - commit ed0b0b66dc38da1a2b68be1185ad557d1201c5e6
>    - main script:
>
> https://notabug.org/broncodev/petsc-pkgbuild/src/ed0b0b66dc38da1a2b68be1185ad557d1201c5e6/PKGBUILD
>    - extra dependencies:
>
> https://notabug.org/broncodev/petsc-pkgbuild/src/ed0b0b66dc38da1a2b68be1185ad557d1201c5e6/test_optdepends.sh
>
>    - This results in the following `configure` flags:
>      #+begin_EXAMPLE
>        LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now
> --prefix=/usr/petsc/linux-c-opt --CXXOPTFLAGS=-O3 --CFLAGS=-fPIC
> -fopenmp -O3 -march=x86-64 -mtune=generic --CXXFLAGS=-fPIC -fopenmp -O3
> -march=x86-64 -mtune=generic --FFLAGS=-fPIC -fopenmp -O3 -march=x86-64
> -mtune=generic --FCFLAGS=-fPIC -fopenmp -O3 -march=x86-64 -mtune=generic
> --F90FLAGS=-fPIC -fopenmp -O3 -march=x86-64 -mtune=generic
> --F77FLAGS=-fPIC -fopenmp -O3 -march=x86-64 -mtune=generic
> --with-cxx-dialect=C++11 --with-fftw=1 --with-hdf5=1 --with-mpi=1
> --with-pic=1 --with-shared-libraries=1 --with-zlib=1
> --with-scalar-type=complex --with-hypre=1 --with-mumps=1 --with-fftw=1
> --with-hdf5=1 --with-scalapack=1 --with-suitesparse=1 --with-metis=1
> --with-parmetis=1 --with-ptscotch=1
> --with-ptscotch-lib="[libesmumps.so,libptscotch.so,libptscotcherr.so,libscotch.so,libscotcherr.so,libbz2.so]"
>
> --with-ptscotch-include=/usr/include/scotch --with-superlu=1
> --with-superlu-lib=-lsuperlu --with-superlu-include=/usr/include/superlu
> --with-eigen=1 --with-eigen-include=/usr/include/eigen3 --with-openmp=1
> --with-hwloc=1 --with-hwloc-pkg-config=/usr/lib/pkgconfig/ --with-cgns=1
> --with-png=1 --with-png-pkg-config=/usr/lib/pkgconfig/ --with-med=1
>      #+end_EXAMPLE
>
>
> - libmesh: https://notabug.org/broncodev/libmesh-pkgbuild
>    - commit 4286225389795cdacec80b1af669f03c2edabb43
>    - main script:
>
> https://notabug.org/broncodev/libmesh-pkgbuild/src/4286225389795cdacec80b1af669f03c2edabb43/PKGBUILD
>    - This results in the following `configure` flags:
>      #+begin_EXAMPLE
>        configure: running /bin/sh ./configure --disable-option-checking
> '--prefix=/usr'  '--enable-petsc-hypre-required' '--with-metis=PETSc'
> '--enable-metaphysicl-required' '--enable-vtk-required' '--enable-curl'
> '--enable-hdf5' '--enable-complex' '--with-pic' '--enable-mpi'
> '--enable-fftw' '--enable-shared' '--enable-unique-id' '--enable-march'
> '--enable-ifem' '--enable-nodeconstraint' 'CXXFLAGS=-fPIC -fopenmp -O3
> -march=x86-64 -mtune=generic'
> 'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'
> 'CPPFLAGS=-fPIC -fopenmp -O3 -march=x86-64 -mtune=generic
> -D_FORTIFY_SOURCE=2' 'CFLAGS=-fPIC -fopenmp -O3 -march=x86-64
> -mtune=generic' 'FCFLAGS=-fPIC -fopenmp -O3 -march=x86-64
> -mtune=generic' 'FFLAGS=-fPIC -fopenmp -O3 -march=x86-64 -mtune=generic'
> 'METHODS=opt oprof dbg' 'PETSC_DIR=/usr/petsc/linux-c-opt'
> '--enable-dap' '--disable-testsets' 'CXX=mpicxx' 'CC=mpicc' 'F77=mpif77'
> 'FC=mpif90' 'CPPFLAGS= -fPIC -fopenmp -O3 -march=x86-64 -mtune=generic
> -D_FORTIFY_SOURCE=2' 'LIBS=-L/lib -lhdf5 -Wl,-rpath,/lib -ldl '
> --cache-file=/dev/null --srcdir=.
>      #+end_EXAMPLE
>
>
> ** The error is this:
>
> #+begin_EXAMPLE
>    make  check-TESTS
>    make[4]: Entering directory
> '/folder/libmesh/examples/reduced_basis/reduced_basis_ex7'
>    ,***************************************************************
>    ,* Running Example reduced_basis_ex7:
>    ,*   ./example-dbg -online_mode 0 -ksp_type preonly -pc_type lu
> -pc_factor_mat_solver_type mumps
>    ,***************************************************************
>
>    Error: Solver  is unknown.
>    WARNING! There are options you set that were not used!
>    WARNING! could be spelling mistake, etc!
>    There are 4 unused database options. They are:
>    Option left: name:-ksp_type value: preonly
>    Option left: name:-online_mode value: 0
>    Option left: name:-pc_factor_mat_solver_type value: mumps
>    Option left: name:-pc_type value: lu


Hmm... it seems to me that you should not hit exactly this error because of
this logic:

  // check that we have the required solver:
  std::string solver;
  solver = input.next(solver);
  if (solver == "mumps")
  {
#ifndef LIBMESH_PETSC_HAVE_MUMPS
    libmesh_example_requires(false, "PETSc compiled with MUMPS support");
#endif
  }
  else if (solver == "superlu")
  {
#ifndef LIBMESH_PETSC_HAVE_SUPERLU_DIST
    libmesh_example_requires(false, "PETSc compiled with SuperLU support");
#endif
  }
  else
  {
     libMesh::err << "Error: Solver " << solver << " is unknown."
                  << std::endl;
     return 1;
  }

i.e. you should hit the "libmesh_example_requires" in the first if-block.
But perhaps you are using an older version of libmesh which doesn't have
this check.

Either way, it's not fatal error with your libmesh build, just an example
that requires a specific solver that you don't have in your build of PETSc.

-- 
John

[Libmesh-users] make check Error: Solver is unknown.

[<ed...@op...>]

Hello,

I am getting an error with `make check`. I can live with another 
compilation that I already have, but if you want the debugging 
information, let me know.


** Compilation set-up of PETSc and libmesh

My compilation configuration can be seen here:

- PETSc:
   - https://notabug.org/broncodev/petsc-pkgbuild
     - commit ed0b0b66dc38da1a2b68be1185ad557d1201c5e6
   - main script: 
https://notabug.org/broncodev/petsc-pkgbuild/src/ed0b0b66dc38da1a2b68be1185ad557d1201c5e6/PKGBUILD
   - extra dependencies: 
https://notabug.org/broncodev/petsc-pkgbuild/src/ed0b0b66dc38da1a2b68be1185ad557d1201c5e6/test_optdepends.sh

   - This results in the following `configure` flags:
     #+begin_EXAMPLE
       LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now 
--prefix=/usr/petsc/linux-c-opt --CXXOPTFLAGS=-O3 --CFLAGS=-fPIC 
-fopenmp -O3 -march=x86-64 -mtune=generic --CXXFLAGS=-fPIC -fopenmp -O3 
-march=x86-64 -mtune=generic --FFLAGS=-fPIC -fopenmp -O3 -march=x86-64 
-mtune=generic --FCFLAGS=-fPIC -fopenmp -O3 -march=x86-64 -mtune=generic 
--F90FLAGS=-fPIC -fopenmp -O3 -march=x86-64 -mtune=generic 
--F77FLAGS=-fPIC -fopenmp -O3 -march=x86-64 -mtune=generic 
--with-cxx-dialect=C++11 --with-fftw=1 --with-hdf5=1 --with-mpi=1 
--with-pic=1 --with-shared-libraries=1 --with-zlib=1 
--with-scalar-type=complex --with-hypre=1 --with-mumps=1 --with-fftw=1 
--with-hdf5=1 --with-scalapack=1 --with-suitesparse=1 --with-metis=1 
--with-parmetis=1 --with-ptscotch=1 
--with-ptscotch-lib="[libesmumps.so,libptscotch.so,libptscotcherr.so,libscotch.so,libscotcherr.so,libbz2.so]" 
--with-ptscotch-include=/usr/include/scotch --with-superlu=1 
--with-superlu-lib=-lsuperlu --with-superlu-include=/usr/include/superlu 
--with-eigen=1 --with-eigen-include=/usr/include/eigen3 --with-openmp=1 
--with-hwloc=1 --with-hwloc-pkg-config=/usr/lib/pkgconfig/ --with-cgns=1 
--with-png=1 --with-png-pkg-config=/usr/lib/pkgconfig/ --with-med=1
     #+end_EXAMPLE


- libmesh: https://notabug.org/broncodev/libmesh-pkgbuild
   - commit 4286225389795cdacec80b1af669f03c2edabb43
   - main script: 
https://notabug.org/broncodev/libmesh-pkgbuild/src/4286225389795cdacec80b1af669f03c2edabb43/PKGBUILD
   - This results in the following `configure` flags:
     #+begin_EXAMPLE
       configure: running /bin/sh ./configure --disable-option-checking 
'--prefix=/usr'  '--enable-petsc-hypre-required' '--with-metis=PETSc' 
'--enable-metaphysicl-required' '--enable-vtk-required' '--enable-curl' 
'--enable-hdf5' '--enable-complex' '--with-pic' '--enable-mpi' 
'--enable-fftw' '--enable-shared' '--enable-unique-id' '--enable-march' 
'--enable-ifem' '--enable-nodeconstraint' 'CXXFLAGS=-fPIC -fopenmp -O3 
-march=x86-64 -mtune=generic' 
'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now' 
'CPPFLAGS=-fPIC -fopenmp -O3 -march=x86-64 -mtune=generic 
-D_FORTIFY_SOURCE=2' 'CFLAGS=-fPIC -fopenmp -O3 -march=x86-64 
-mtune=generic' 'FCFLAGS=-fPIC -fopenmp -O3 -march=x86-64 
-mtune=generic' 'FFLAGS=-fPIC -fopenmp -O3 -march=x86-64 -mtune=generic' 
'METHODS=opt oprof dbg' 'PETSC_DIR=/usr/petsc/linux-c-opt' 
'--enable-dap' '--disable-testsets' 'CXX=mpicxx' 'CC=mpicc' 'F77=mpif77' 
'FC=mpif90' 'CPPFLAGS= -fPIC -fopenmp -O3 -march=x86-64 -mtune=generic 
-D_FORTIFY_SOURCE=2' 'LIBS=-L/lib -lhdf5 -Wl,-rpath,/lib -ldl ' 
--cache-file=/dev/null --srcdir=.
     #+end_EXAMPLE


** The error is this:

#+begin_EXAMPLE
   make  check-TESTS
   make[4]: Entering directory 
'/folder/libmesh/examples/reduced_basis/reduced_basis_ex7'
   ,***************************************************************
   ,* Running Example reduced_basis_ex7:
   ,*   ./example-dbg -online_mode 0 -ksp_type preonly -pc_type lu 
-pc_factor_mat_solver_type mumps
   ,***************************************************************

   Error: Solver  is unknown.
   WARNING! There are options you set that were not used!
   WARNING! could be spelling mistake, etc!
   There are 4 unused database options. They are:
   Option left: name:-ksp_type value: preonly
   Option left: name:-online_mode value: 0
   Option left: name:-pc_factor_mat_solver_type value: mumps
   Option left: name:-pc_type value: lu

    
----------------------------------------------------------------------------
   | Reference count information                                          
       |
    
----------------------------------------------------------------------------
   | N7libMesh4ElemE reference count information:
   |  Creations:    1
   |  Destructions: 1
   | N7libMesh9DofObjectE reference count information:
   |  Creations:    1
   |  Destructions: 1
    
----------------------------------------------------------------------------
   FAIL: run.sh
   ====================================================
   1 of 1 test failed
   Please report to lib...@li...
   ====================================================
   make[4]: *** [Makefile:1009: check-TESTS] Error 1
   make[4]: Leaving directory 
'/folder/libmesh/examples/reduced_basis/reduced_basis_ex7'
   make[3]: *** [Makefile:1136: check-am] Error 2
   make[3]: Leaving directory 
'/folder/libmesh/examples/reduced_basis/reduced_basis_ex7'
   make[2]: *** [Makefile:1138: check] Error 2
   make[2]: Leaving directory 
'/folder/libmesh/examples/reduced_basis/reduced_basis_ex7'
   make[1]: *** [Makefile:727: check-recursive] Error 1
   make[1]: Leaving directory '/folder/libmesh/examples'
   make: *** [Makefile:31749: check-recursive] Error 1
#+end_EXAMPLE

If you need more information, please, let me know

-------------------------------------------------
This free account was provided by VFEmail.net - report spam to ab...@vf...
 
ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  

Re: [Libmesh-users] Help with compiling, please

[John P. <jwp...@gm...>]

On Fri, Dec 20, 2019 at 6:09 AM <ed...@op...> wrote:

> Hi!
>
> The compilation with v1.5.1 worked. I attach my PKGBUILD in case that
> it's useful (should be self-explanatory even for other flavours of
> Linux).
>
> I'm having trouble with building the documentation, but I'll get to
> that.
>
> By the way, it was a pain to subscribe to the mailing list (due to
> source-forge and cloudfront).
>

Sorry about that. It has been a long overdue goal of mine to move the old
mailing list over to something else like google groups. Our statistics show
that not many people are subscribed to or use either of the lists much any
more, so it has not been a high priority.

-- 
John

Re: [Libmesh-users] Help with compiling, please

[<ed...@op...>]

Hi!

The compilation with v1.5.1 worked. I attach my PKGBUILD in case that 
it's useful (should be self-explanatory even for other flavours of 
Linux).

I'm having trouble with building the documentation, but I'll get to 
that.

By the way, it was a pain to subscribe to the mailing list (due to 
source-forge and cloudfront).


On 2019-12-18 20:02, Stogner, Roy H wrote:
> Are you building on top of libMesh alone, or on top of middleware that
> requires a very recent libMesh git version?
> 
> If the former, I'd suggest trying the libMesh 1.5.1 release, which
> doesn't include the refactoring that's breaking on your system.
> 
> If the latter, you might try an out-of-source build?
> 
> # e.g.:
> mkdir my_build_dir
> cd my_build_dir
> ../configure --prefix=/usr --enable-petsc PETSC_DIR="$petsc_dir"
> 
> I do think I see what's breaking, except that if I'm right I can't
> believe nobody else triggered such an embarrassing bug yet.  If I can
> replicate the problem I'll fix it ASAP; if not then I'd appreciate
> your help later verifying whether or not a potential fix works.
> 
> Thanks for the report,
> ---
> Roy


-------------------------------------------------
This free account was provided by VFEmail.net - report spam to ab...@vf...
 
ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  

Re: [Libmesh-users] Help with compiling, please

[Stogner, R. H <roy...@ic...>]

Are you building on top of libMesh alone, or on top of middleware that
requires a very recent libMesh git version?

If the former, I'd suggest trying the libMesh 1.5.1 release, which
doesn't include the refactoring that's breaking on your system.

If the latter, you might try an out-of-source build?

# e.g.:
mkdir my_build_dir
cd my_build_dir
../configure --prefix=/usr --enable-petsc PETSC_DIR="$petsc_dir"

I do think I see what's breaking, except that if I'm right I can't
believe nobody else triggered such an embarrassing bug yet.  If I can
replicate the problem I'll fix it ASAP; if not then I'd appreciate
your help later verifying whether or not a potential fix works.

Thanks for the report,
---
Roy

[Libmesh-users] Help with compiling, please

[<ed...@op...>]

Hello,

I am trying to compile in Parabola x86_64 GNU/Linux, and keep getting 
errors. Any help is appreciated. I attach my PKGBUILD (script to 
compile; small summary below) in case that it is useful, my log and a 
summary of errors (which can also be found in the log):

== Errors (summary) ==
     error: #include nested too deeply

     ./include/libmesh/parallel_object.h:63:35: error: 'Communicator' in 
namespace 'libMesh::Parallel' does not name a type

     ./include/libmesh/parallel_object.h:101:40: error: invalid use of 
incomplete type 'const class libMesh::Parallel::Communicator'

     ./include/libmesh/parallel_algebra.h:90:5: error: there are no 
arguments to 'timpi_call_mpi' that depend on a template parameter, so a 
declaration of 'timpi_call_mpi' must be available [-fpermissive]

     ./include/libmesh/parallel_algebra.h:173:7: error: class 
'TIMPI::StandardType<libMesh::VectorValue<T> >' does not have any field 
named 'DataType'

Similar issues happen without PETSc


== Building instructions (summary) ==
   sed -i 's-=[[:space:]]*../../-=https://github.com/-g' .gitmodules
   git submodule sync --recursive
   git submodule update --init

   # Find the directory where PETSc is
   petsc_h=$(pacman -Ql petsc | grep -m 1 petsc.h | sed 's-^[[:alpha:]-]* 
--g')
   petsc_dir=$(dirname "$petsc_h")
   petsc_dir=${petsc_dir%%/include}

   ./configure --prefix=/usr --enable-petsc PETSC_DIR="$petsc_dir"
   make

-------------------------------------------------
This free account was provided by VFEmail.net - report spam to ab...@vf...
 
ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  

[Libmesh-users] Tenure-track faculty positions at San Diego State University

[Amneet B. <mai...@gm...>]

Dear Colleagues,

Apologies in advance if you are reading these job ads from multiple mailing
lists.

The Department of Mechanical Engineering at San Diego State University
seeks to fill two tenure-track positions at the Assistant Professor level
in the areas of computational mechanics and renewable energy conversion and
storage starting Fall 2020.

Candidates having expertise in large scale computations and
state-of-the-art machine learning and data-driven model development
techniques in these areas are particularly encouraged to apply.

Applicants must have an earned Ph.D. degree in mechanical engineering or a
closely related discipline. Applications received by January 20, 2020 will
receive full consideration; the position will remain open until filled.
Candidates must apply via Interfolio at https://apply.interfolio.com/72480
[computational mechanics position] and https://apply.interfolio.com/72479
[renewable energy conversion and storage position]. Questions related to
this search may be addressed to mec...@sd....

Please refer to the attached job ads for further information.

Thanks and kind regards,
-- 
Amneet Bhalla
Assistant Professor, Department of Mechanical Engineering
San Diego State University
5500 Campanile Drive
San Diego, CA 92182 USA
Web: https://bhallagroup.wixsite.com/cfdlab

Re: [Libmesh-users] undefined M_PI

[Stogner, R. H <roy...@ic...>]

On Wed, 11 Dec 2019, Povolotskyi, Mykhailo wrote:

> I have encountered a problem with M_PI symbol:

M_PI is defined by any Unix98-standard math.h

https://pubs.opengroup.org/onlinepubs/009695399/basedefs/math.h.html

But if you're not using a Unix98 math.h you might have a problem?

There's a workaround for MSVC which nanoflann.hpp already uses but
which is kind of fragile, for instance:
https://stackoverflow.com/questions/6563810/m-pi-works-with-math-h-but-not-with-cmath-in-visual-studio

And if you're using yet-another non-Unix98 math.h still then you might
need a different workaround or there might be no workaround other than
defining M_PI (and any other missing symbols, of which there hopefully
aren't too too many) yourself.
---
Roy

[Libmesh-users] undefined M_PI

[Povolotskyi, M. <mpo...@pu...>]

Hello,

I have encountered a problem with M_PI symbol:


In file included from 
/home/michael/libs/libmesh/libmesh_install_1.5.1/include/libmesh/meshfree_interpolation.h:30:0,
                  from ReadDopantConcentration.C:4:
/home/michael/libs/libmesh/libmesh_install_1.5.1/include/libmesh/nanoflann.hpp: 
In member function ‘nanoflann::SO2_Adaptor<T, DataSource, 
_DistanceType>::DistanceType nanoflann::SO2_Adaptor<T, DataSource, 
_DistanceType>::accum_dist(U, V, int) const’:
/home/michael/libs/libmesh/libmesh_install_1.5.1/include/libmesh/nanoflann.hpp:413:17: 
error: ‘M_PI’ was not declared in this scope
     if (result > M_PI)
                  ^~~~
/home/michael/libs/libmesh/libmesh_install_1.5.1/include/libmesh/nanoflann.hpp:413:17: 
note: suggested alternative: ‘__P’
     if (result > M_PI)
                  ^~~~

Please advise,

Michael.

Re: [Libmesh-users] problems with pthread_spin_init

[Povolotskyi, M. <mpo...@pu...>]

Thank you,

I'll try to disable the pthreads.

Michael.

On 12/09/2019 07:00 PM, John Peterson wrote:


On Mon, Dec 9, 2019 at 5:45 PM Povolotskyi, Mykhailo <mpo...@pu...<mailto:mpo...@pu...>> wrote:

Hello John,

due to some reasons I have to build my code on Windows.

So, I have cygwin and I managed to locate several pthread.h. They are in the following directories:

C:\cygwin64\usr\i686-pc-cygwin\sys-root\usr\include

C:\cygwin64\usr\i686-w64-mingw32\sys-root\mingw\include

C:\cygwin64\usr\include

C:\cygwin64\usr\x86_64-w64-mingw32\sys-root\mingw\include

OK, well the best thing to do is probably configure with --disable-pthreads.

Also you may want to look into something called "MSys2," as there was a user not long ago who I believe got everything to compile using that.

https://github.com/libMesh/libmesh/pull/1388

--
John

Re: [Libmesh-users] problems with pthread_spin_init

[John P. <jwp...@gm...>]

On Mon, Dec 9, 2019 at 5:45 PM Povolotskyi, Mykhailo <mpo...@pu...>
wrote:

> Hello John,
>
> due to some reasons I have to build my code on Windows.
>
> So, I have cygwin and I managed to locate several pthread.h. They are in
> the following directories:
>
> C:\cygwin64\usr\i686-pc-cygwin\sys-root\usr\include
>
> C:\cygwin64\usr\i686-w64-mingw32\sys-root\mingw\include
>
> C:\cygwin64\usr\include
>
> C:\cygwin64\usr\x86_64-w64-mingw32\sys-root\mingw\include
>

OK, well the best thing to do is probably configure with --disable-pthreads.

Also you may want to look into something called "MSys2," as there was a
user not long ago who I believe got everything to compile using that.

https://github.com/libMesh/libmesh/pull/1388

-- 
John

Re: [Libmesh-users] problems with pthread_spin_init

[John P. <jwp...@gm...>]

On Mon, Dec 9, 2019 at 5:02 PM Povolotskyi, Mykhailo <mpo...@pu...>
wrote:

> Dear Libmesh developers,
>
> I have problems when I include the header files (see bellow).
>
> I'll be happy to provide any other files that might help.
>
> Thank you,
>
> Michael.
>
>
> In file included from
>
> /home/michael/libs/libmesh/libmesh_install_1.5.1/include/libmesh/threads.h:104:0,
>                   from
>
> /home/michael/libs/libmesh/libmesh_install_1.5.1/include/libmesh/reference_counter.h:25,
>                   from
>
> /home/michael/libs/libmesh/libmesh_install_1.5.1/include/libmesh/reference_counted_object.h:24,
>                   from
>
> /home/michael/libs/libmesh/libmesh_install_1.5.1/include/libmesh/dof_object.h:28,
>                   from
>
> /home/michael/libs/libmesh/libmesh_install_1.5.1/include/libmesh/mesh_base.h:25,
>                   from
>
> /home/michael/libs/libmesh/libmesh_install_1.5.1/include/libmesh/unstructured_mesh.h:24,
>                   from
>
> /home/michael/libs/libmesh/libmesh_install_1.5.1/include/libmesh/replicated_mesh.h:24,
>                   from
> /home/michael/libs/libmesh/libmesh_install_1.5.1/include/libmesh/mesh.h:30,
>                   from ImportMesh.C:2:
> /home/michael/libs/libmesh/libmesh_install_1.5.1/include/libmesh/threads_pthread.h:
>
> In constructor ‘libMesh::Threads::spin_mutex::spin_mutex()’:
> /home/michael/libs/libmesh/libmesh_install_1.5.1/include/libmesh/threads_pthread.h:146:18:
>
> error: ‘pthread_spin_init’ was not declared in this scope
>     spin_mutex() { pthread_spin_init(&slock, PTHREAD_PROCESS_PRIVATE); }
>


Hi,

It looks like you are on a system with a non-standard pthreads
implementation? It appears that LIBMESH_HAVE_PTHREAD is true, so the
relevant configure tests passed, but it doesn't test for
pthread_spin_init(). I'm skeptical of this... can you locate pthread.h on
your system and let us know where it comes from, etc., especially if it is
not the GNU C one?

-- 
John

[Libmesh-users] problems with pthread_spin_init

[Povolotskyi, M. <mpo...@pu...>]

Dear Libmesh developers,

I have problems when I include the header files (see bellow).

I'll be happy to provide any other files that might help.

Thank you,

Michael.


In file included from 
/home/michael/libs/libmesh/libmesh_install_1.5.1/include/libmesh/threads.h:104:0,
                  from 
/home/michael/libs/libmesh/libmesh_install_1.5.1/include/libmesh/reference_counter.h:25,
                  from 
/home/michael/libs/libmesh/libmesh_install_1.5.1/include/libmesh/reference_counted_object.h:24,
                  from 
/home/michael/libs/libmesh/libmesh_install_1.5.1/include/libmesh/dof_object.h:28,
                  from 
/home/michael/libs/libmesh/libmesh_install_1.5.1/include/libmesh/mesh_base.h:25,
                  from 
/home/michael/libs/libmesh/libmesh_install_1.5.1/include/libmesh/unstructured_mesh.h:24,
                  from 
/home/michael/libs/libmesh/libmesh_install_1.5.1/include/libmesh/replicated_mesh.h:24,
                  from 
/home/michael/libs/libmesh/libmesh_install_1.5.1/include/libmesh/mesh.h:30,
                  from ImportMesh.C:2:
/home/michael/libs/libmesh/libmesh_install_1.5.1/include/libmesh/threads_pthread.h: 
In constructor ‘libMesh::Threads::spin_mutex::spin_mutex()’:
/home/michael/libs/libmesh/libmesh_install_1.5.1/include/libmesh/threads_pthread.h:146:18: 
error: ‘pthread_spin_init’ was not declared in this scope
    spin_mutex() { pthread_spin_init(&slock, PTHREAD_PROCESS_PRIVATE); }
                   ^~~~~~~~~~~~~~~~~
/home/michael/libs/libmesh/libmesh_install_1.5.1/include/libmesh/threads_pthread.h:146:18: 
note: suggested alternative: ‘pthread_cond_init’
    spin_mutex() { pthread_spin_init(&slock, PTHREAD_PROCESS_PRIVATE); }
                   ^~~~~~~~~~~~~~~~~
                   pthread_cond_init
/home/michael/libs/libmesh/libmesh_install_1.5.1/include/libmesh/threads_pthread.h: 
In destructor ‘libMesh::Threads::spin_mutex::~spin_mutex()’:
/home/michael/libs/libmesh/libmesh_install_1.5.1/include/libmesh/threads_pthread.h:147:19: 
error: ‘pthread_spin_destroy’ was not declared in this scope
    ~spin_mutex() { pthread_spin_destroy(&slock); }
                    ^~~~~~~~~~~~~~~~~~~~
/home/michael/libs/libmesh/libmesh_install_1.5.1/include/libmesh/threads_pthread.h:147:19: 
note: suggested alternative: ‘pthread_cond_destroy’
    ~spin_mutex() { pthread_spin_destroy(&slock); }
                    ^~~~~~~~~~~~~~~~~~~~
                    pthread_cond_destroy
/home/michael/libs/libmesh/libmesh_install_1.5.1/include/libmesh/threads_pthread.h: 
In member function ‘void libMesh::Threads::spin_mutex::lock()’:
/home/michael/libs/libmesh/libmesh_install_1.5.1/include/libmesh/threads_pthread.h:149:18: 
error: ‘pthread_spin_lock’ was not declared in this scope
    void lock () { pthread_spin_lock(&slock); }
                   ^~~~~~~~~~~~~~~~~
/home/michael/libs/libmesh/libmesh_install_1.5.1/include/libmesh/threads_pthread.h:149:18: 
note: suggested alternative: ‘pthread_spinlock_t’
    void lock () { pthread_spin_lock(&slock); }
                   ^~~~~~~~~~~~~~~~~
                   pthread_spinlock_t
/home/michael/libs/libmesh/libmesh_install_1.5.1/include/libmesh/threads_pthread.h: 
In member function ‘void libMesh::Threads::spin_mutex::unlock()’:
/home/michael/libs/libmesh/libmesh_install_1.5.1/include/libmesh/threads_pthread.h:150:20: 
error: ‘pthread_spin_unlock’ was not declared in this scope
    void unlock () { pthread_spin_unlock(&slock); }
                     ^~~~~~~~~~~~~~~~~~~
/home/michael/libs/libmesh/libmesh_install_1.5.1/include/libmesh/threads_pthread.h:150:20: 
note: suggested alternative: ‘pthread_mutex_unlock’
    void unlock () { pthread_spin_unlock(&slock); }
                     ^~~~~~~~~~~~~~~~~~~
                     pthread_mutex_unlock

Re: [Libmesh-users] failure in libmesh instalation

[Povolotskyi, M. <mpo...@pu...>]

Thank you

--disable-tecio solved the problem for now.

Michael.

On 12/8/2019 3:41 PM, John Peterson wrote:


On Sat, Dec 7, 2019 at 10:29 PM Povolotskyi, Mykhailo <mpo...@pu...<mailto:mpo...@pu...>> wrote:
Hello,

I'm installing   libmesh-1.5.1.

Here is the error message:

tecsrc/arrlist.cpp:390:26: error: ‘VALID_REF’ was not declared in this scope
      Boolean_t IsValid = (VALID_REF(ArrayList) &&
                           ^~~~~~~~~
tecsrc/arrlist.cpp:390:26: note: suggested alternative: ‘INVALID_REF’
      Boolean_t IsValid = (VALID_REF(ArrayList) &&
                           ^~~~~~~~~
                           INVALID_REF

I attach the log file.


Hello,

It's not clear to me what would cause this to happen. The macro in question can be found in the TASSERT.h header:

contrib/tecplot/tecio/tecsrc/TASSERT.h:#    define VALID_REF(p)      ( (p)  != NULL )

You may want to investigate some of the surrounding logic to see whether any of it applies to the system you're on? The tecio source never changes, and we haven't change the way that we build it, so my guess is there's something about your system that we have not encountered before. You might also consider configuring with --disable-tecio and see if you can just avoid the problem, assuming you don't need to write Tecplot binary files.

--
John

Re: [Libmesh-users] failure in libmesh instalation

[John P. <jwp...@gm...>]

On Sat, Dec 7, 2019 at 10:29 PM Povolotskyi, Mykhailo <mpo...@pu...>
wrote:

> Hello,
>
> I'm installing   libmesh-1.5.1.
>
> Here is the error message:
>
> tecsrc/arrlist.cpp:390:26: error: ‘VALID_REF’ was not declared in this
> scope
>       Boolean_t IsValid = (VALID_REF(ArrayList) &&
>                            ^~~~~~~~~
> tecsrc/arrlist.cpp:390:26: note: suggested alternative: ‘INVALID_REF’
>       Boolean_t IsValid = (VALID_REF(ArrayList) &&
>                            ^~~~~~~~~
>                            INVALID_REF
>
> I attach the log file.
>


Hello,

It's not clear to me what would cause this to happen. The macro in question
can be found in the TASSERT.h header:

contrib/tecplot/tecio/tecsrc/TASSERT.h:#    define VALID_REF(p)      ( (p)
 != NULL )

You may want to investigate some of the surrounding logic to see whether
any of it applies to the system you're on? The tecio source never changes,
and we haven't change the way that we build it, so my guess is there's
something about your system that we have not encountered before. You might
also consider configuring with --disable-tecio and see if you can just
avoid the problem, assuming you don't need to write Tecplot binary files.

-- 
John

[Libmesh-users] failure in libmesh instalation

[Povolotskyi, M. <mpo...@pu...>]

Hello,

I'm installing   libmesh-1.5.1.

Here is the error message:

tecsrc/arrlist.cpp:390:26: error: ‘VALID_REF’ was not declared in this scope
      Boolean_t IsValid = (VALID_REF(ArrayList) &&
                           ^~~~~~~~~
tecsrc/arrlist.cpp:390:26: note: suggested alternative: ‘INVALID_REF’
      Boolean_t IsValid = (VALID_REF(ArrayList) &&
                           ^~~~~~~~~
                           INVALID_REF

I attach the log file.

Please advise.

Thank you,

Michael.

Re: [Libmesh-users] How to fix values of individual dofs

[Prashant K. J. <pra...@gm...>]

Hi Roy,

Great. After identifying nodes and element with boundary id, It works.
Thank you!

Regards,
Prashant

On Thu, Dec 5, 2019 at 1:08 PM Stogner, Roy H <roy...@ic...>
wrote:

>
> On Thu, 5 Dec 2019, Prashant Kumar Jha wrote:
>
> > I am not setting boundary id of the element (can we set them?).
>
> Yes, with BoundaryInfo::add_side().
>
> > For Dirichlet boundary condition on 1 dof, I am not sure how to put a
> constraint row.
>
> With DofMap::add_constraint_row() (using the overload with the
> constraint_rhs argument, unless you only ever have homogeneous
> Dirichlet boundaries).
> ---
> Roy



-- 
Regards,
Prashant

https://www.math.lsu.edu/~jha/

Re: [Libmesh-users] How to fix values of individual dofs

[Stogner, R. H <roy...@ic...>]

On Thu, 5 Dec 2019, Prashant Kumar Jha wrote:

> I am not setting boundary id of the element (can we set them?). 

Yes, with BoundaryInfo::add_side().

> For Dirichlet boundary condition on 1 dof, I am not sure how to put a constraint row. 

With DofMap::add_constraint_row() (using the overload with the
constraint_rhs argument, unless you only ever have homogeneous
Dirichlet boundaries).
---
Roy

Re: [Libmesh-users] How to fix values of individual dofs

[Prashant K. J. <pra...@gm...>]

Hi Roy,

Below is how I create mesh, nodes, and elements:

ReplicatedMesh mesh(*comm);

// create list of nodes and segments
std::vector<unsigned int> nodes;
std::vector<unsigned int> elems;

// create two nodes at point (0,0,0) and (1,1,1) and element between these
// nodes
{
  auto add_node = mesh.add_point(Point(0., 0., 0.));
  nodes.push_back(add_node->id());

  add_node = mesh.add_point(Point(1., 1., 1.));
  nodes.push_back(add_node->id());

  auto elem = Elem::build(EDGE2).release();
  elem->set_node(0) = mesh.node_ptr(nodes[0]);
  elem->set_node(1) = mesh.node_ptr(nodes[1]);
  auto add_elem = mesh.add_elem(elem);
  elems.push_back(add_elem->id());

  // finish adding nodes and elements
  mesh.prepare_for_use();
}

// add equation system for pressure
EquationSystems eq_sys(mesh);
auto &flow = eq_sys.add_system<TransientLinearImplicitSystem>("Flow");
flow.add_variable("pressure", FIRST);
flow.time = 0.0;

// attach initial condition
flow.attach_init_function(initial_condition);

// attach assembly function
flow.attach_assemble_function(assemble_net);

// fix value of first node (Dirichlet boundary condition)
{
  // auto elem_0 = mesh.elem(elems[0]);
  // flow.get_dof_map().constrain_p_dofs(0, elem_0, 0, elem_0->level());

  std::set<boundary_id_type> boundary_ids;
  boundary_ids.insert(0);
  std::vector<unsigned int> variables = {0};
  ConstFunction<Number> df(2);

  DirichletBoundary diri_bc(boundary_ids, variables, &df);

  flow.get_dof_map().add_dirichlet_boundary(diri_bc);
}
eq_sys.init();


I am not setting boundary id of the element (can we set them?).

For Dirichlet boundary condition on 1 dof, I am not sure how to put a
constraint row.

Regards,
Prashant

On Thu, Dec 5, 2019 at 12:52 PM Stogner, Roy H <roy...@ic...>
wrote:

>
> On Thu, 5 Dec 2019, Prashant Kumar Jha wrote:
>
> > I can create a network mesh consisting of edge elements in 3D space. This
> > is non-standard mesh in the sense that I start with empty mesh, add
> couple
> > of nodes, add edge element between nodes. Each node has 1 pressure dof.
> On
> > this network, I am now trying to solve 1D pde for pressure. For boundary
> > conditions, I want to fix the two ends of the network (i.e. the first dof
> > and the last dof) to a specific value.
> >
> > DirichletBoundary with boundary id 0 and 1 result in error possibly due
> to
> > mesh in 3D where as elements are of 1D nature.
>
> That shouldn't be the case.  What exactly is the error?  Did you set
> the boundary ids when you created the mesh?
>
> > To get around this, I was wondering if I could fix the individual dof to
> a
> > specific value. Any suggestions to make above work is appreciated.
>
> You can manually add a constraint row for each boundary dof, or you
> can use a penalty method.
> ---
> Roy
>


-- 
Regards,
Prashant

https://www.math.lsu.edu/~jha/

Re: [Libmesh-users] How to fix values of individual dofs

[Stogner, R. H <roy...@ic...>]

On Thu, 5 Dec 2019, Prashant Kumar Jha wrote:

> I can create a network mesh consisting of edge elements in 3D space. This
> is non-standard mesh in the sense that I start with empty mesh, add couple
> of nodes, add edge element between nodes. Each node has 1 pressure dof. On
> this network, I am now trying to solve 1D pde for pressure. For boundary
> conditions, I want to fix the two ends of the network (i.e. the first dof
> and the last dof) to a specific value.
>
> DirichletBoundary with boundary id 0 and 1 result in error possibly due to
> mesh in 3D where as elements are of 1D nature.

That shouldn't be the case.  What exactly is the error?  Did you set
the boundary ids when you created the mesh?

> To get around this, I was wondering if I could fix the individual dof to a
> specific value. Any suggestions to make above work is appreciated.

You can manually add a constraint row for each boundary dof, or you
can use a penalty method.
---
Roy

[Libmesh-users] How to fix values of individual dofs

[Prashant K. J. <pra...@gm...>]

Hi All,

I can create a network mesh consisting of edge elements in 3D space. This
is non-standard mesh in the sense that I start with empty mesh, add couple
of nodes, add edge element between nodes. Each node has 1 pressure dof. On
this network, I am now trying to solve 1D pde for pressure. For boundary
conditions, I want to fix the two ends of the network (i.e. the first dof
and the last dof) to a specific value.

DirichletBoundary with boundary id 0 and 1 result in error possibly due to
mesh in 3D where as elements are of 1D nature.

To get around this, I was wondering if I could fix the individual dof to a
specific value. Any suggestions to make above work is appreciated.

Regards,
Prashant

Re: [Libmesh-users] L2 Projection between meshes with split dofs

[Renato P. <re...@gm...>]

Cool, thanks!

On Fri, Nov 22, 2019 at 4:24 PM Stogner, Roy H <roy...@ic...>
wrote:

>
> On Fri, 22 Nov 2019, Renato Poli wrote:
>
> > I am alternatively considering a global L2 Glaerkin mapping.
> >
> > Something like - find f_i where:
> >         f(x,y)=f_i \phi_i   (new mesh)
> >         g(x,y)                  (function evaluated in the old mesh)
> >         \int f(x,y) \phi dA = \int g(x,y) \phi dA
> >
> > It make take more time,
>
> It may take more CPU time but I bet it'll be *much* cheaper in
> programmer-hours.
>
> > but it looks safe ... doesn't it?
>
> That depends on your problem and your formulation, I think.  Global
> projections can be a great way to maintain conservation, but they're
> prone to "ringing" artifacts, and either one of those factors can be
> critically important or nearly inconsequential depending on what
> you're solving and how.
> ---
> Roy

Re: [Libmesh-users] L2 Projection between meshes with split dofs

[Stogner, R. H <roy...@ic...>]

On Fri, 22 Nov 2019, Renato Poli wrote:

> I am alternatively considering a global L2 Glaerkin mapping.
> 
> Something like - find f_i where:
>         f(x,y)=f_i \phi_i   (new mesh)
>         g(x,y)                  (function evaluated in the old mesh)
>         \int f(x,y) \phi dA = \int g(x,y) \phi dA
> 
> It make take more time,

It may take more CPU time but I bet it'll be *much* cheaper in
programmer-hours.

> but it looks safe ... doesn't it?

That depends on your problem and your formulation, I think.  Global
projections can be a great way to maintain conservation, but they're
prone to "ringing" artifacts, and either one of those factors can be
critically important or nearly inconsequential depending on what
you're solving and how. 
---
Roy

Re: [Libmesh-users] L2 Projection between meshes with split dofs

[Stogner, R. H <roy...@ic...>]

On Thu, 21 Nov 2019, Renato Poli wrote:

> I have a doubt on L2 projection between meshes with split dofs.
>
> I am currently using the following code to project values from one mesh to
> another more refined one (I perform refinement myself):
>
>      MeshFunction * mesh_func = new MeshFunction( . . . );
>      mesh_func->init();
>      mesh_func->enable_out_of_mesh_mode( 0 );
>      sys.project_solution( ... )
>
> I can see it interpolates the projected values based on the coordinate of
> the dofs. Is that so?

With the MeshFunction interface, yes, I'm afraid so.  When we do our
own mesh refinement then we have more context available, but we can't
get that context to a MeshFunction, because FunctionBase::operator()
only takes a Point, not a Node or Elem.

> It happens that in some coordinates I have duplicated dofs representing
> fractures. Displacements are different on both sides of the fracture even
> though their coordinates are the same.

And then you basically get a value from a random side when it tries to
interpolate at that point.  That's awful.

> Can you see any smart-hack to avoid the interpolation _only_ on fracture
> nodes?

You could create a class that works like MeshFunction but subclasses
FEMFunctionBase instead, so whenever it gets called you have an Elem
as context rather than just a point.  It would be given one of the
*new* Elem objects as context, though, so I don't see how to make this
work generically - it would be specific to your case and you'd have to
handle mapping from new to old elements to determine which side of a
fracture you're on.

> Or should I rewrite the whole 'project_solution' with my own stuff?

Much of the hassle that makes GenericProjector so complicated only
applies if you're also using one advanced feature or another.  If
you're not using any of those features (i.e. you're not using threads,
you're not using p refinement, you're not using hierarchic h
refinement, you're using Lagrange elements only, you're running in
serial) then it'd be a pretty easy rewrite, whereas the more of those
assumptions you can't make the harder it would get.
---
Roy