libmesh-users — General information for libmesh users

[Libmesh-users] XDR files

[Nikhil V. <nik...@gm...>]

Hello,

I am using the reduced basis module. I need to provide a nonzero intial
condition. How can I write an XDR file for this?

Best regards,
Nikhil Vaidya

Re: [Libmesh-users] Elements sharing common vertex/edge

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

Ok, I ended up using David Well's suggestion on using
std::map<Node*,std::set<Elem*> > to map out a node in the mesh to set of
elements sharing that node. Similar stuff for edge --> elements mapping.

The sample code is here:
https://paste.ofcode.org/36JLbnSn4cqFwGJaMyhzLsy

On Mon, Dec 30, 2019 at 11:58 AM Stogner, Roy H <roy...@ic...>
wrote:

>
> On Wed, 25 Dec 2019, Amneet Bhalla wrote:
>
> > I am working with triangulated surfaces in 3D, and I need to:
> >
> > 1) Calculate angle-weighted normals at the vertex points, and
> >
> > 2) Calculate average of normals of two triangles sharing an edge.
> >
> > For both cases, I think I would need to know all elements sharing a
> common
> > vertex, and two elements sharing a common edge, respectively. Can this
> > information extracted from libMesh?
>
> For (1) the answer can be *no* in the case of a distributed mesh with
> default ghosting, but if you use a replicated mesh or you have a
> ghosting functor that includes point neighbors then you can use
> Elem::find_point_neighbors().
>
> For (2) you just use Elem::neighbor_ptr().
> ---
> Roy
>


-- 
--Amneet

Re: [Libmesh-users] building sphere using tetrahedral elements

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

>> 
>> 
>> On Thu, Jan 16, 2020 at 1:21 AM Ramakrishnan Thirumalaisamy <
>> thi...@gm...> wrote:
>> 
>>> Dear libmesh users,
>>> 
>>> I want to create sphere with tetrahedral elements. I came across this
>>> function MeshTools::Generation::build_square. But this function 
>>> supports
>>> only HEX8/27 for 3D.  Is there any other functions in libmesh that I 
>>> could
>>> use to generate sphere with tetrahedral elements?
>>> 
>> 
>> Hi Ramakrishnan,
>> 
>> Your email mentions both spheres and build_square, but I'm assuming 
>> what
>> you're really after is spheres. The implementation doesn't currently 
>> exist,
>> but you could do something similar to what's currently done in the
>> build_cube() case when Tets are selected. That is, first a mesh of
>> hexahedra is created and then each hex is split into IIRC 24 tets. 
>> This
>> isn't the most economical splitting but it is very "symmetric" and
>> therefore easy to make the split elements line up consistently. This
>> splitting also introduces new mid-face nodes, which could be "snapped" 
>> to
>> the sphere surface as necessary.
>> 
>> Another option would be to configure/build libmesh with the
>> --disable-strict-lgpl option and then use the libmesh Tetgen 
>> interfaces to
>> create a Delaunay mesh of the sphere. If you end up implementing 
>> either of
>> those, it would be great if you could contribute them back as either
>> library code or possibly an augmented miscellaneous_ex6.
>> 
>> Note that libmesh also supports reading several different mesh file
>> formats, so if you generate a sphere mesh in e.g. Gmsh, you would be 
>> able
>> to read it in without doing any major programming yourself...
>> 
>> --
>> John
>> 
> 
> _______________________________________________
> Libmesh-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users

On 2020-01-16 17:33, Ramakrishnan Thirumalaisamy wrote:
> Thank you. Sorry for the typo. It should be build_sphere instead of
> build_square.
> 
> Yes. I already created sphere using gmsh and did my numerical 
> experiment.
> But i do not want to keep the mesh files in the remote repository. So I 
> was
> looking to circumvent this by creating sphere using libmesh.
> 
> If I could implement either of your suggestions, I will let you know.
> 
> On Thu, 16 Jan, 2020, 8:26 AM John Peterson, <jwp...@gm...> 
> wrote:
> 

Did you know that you can have a Gmsh script instead of a .msh (or 
another type of) file? (my 2 cents).

-------------------------------------------------
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] building sphere using tetrahedral elements

[Ramakrishnan T. <thi...@gm...>]

Thank you. Sorry for the typo. It should be build_sphere instead of
build_square.

Yes. I already created sphere using gmsh and did my numerical experiment.
But i do not want to keep the mesh files in the remote repository. So I was
looking to circumvent this by creating sphere using libmesh.

If I could implement either of your suggestions, I will let you know.

On Thu, 16 Jan, 2020, 8:26 AM John Peterson, <jwp...@gm...> wrote:

>
>
> On Thu, Jan 16, 2020 at 1:21 AM Ramakrishnan Thirumalaisamy <
> thi...@gm...> wrote:
>
>> Dear libmesh users,
>>
>> I want to create sphere with tetrahedral elements. I came across this
>> function MeshTools::Generation::build_square. But this function supports
>> only HEX8/27 for 3D.  Is there any other functions in libmesh that I could
>> use to generate sphere with tetrahedral elements?
>>
>
> Hi Ramakrishnan,
>
> Your email mentions both spheres and build_square, but I'm assuming what
> you're really after is spheres. The implementation doesn't currently exist,
> but you could do something similar to what's currently done in the
> build_cube() case when Tets are selected. That is, first a mesh of
> hexahedra is created and then each hex is split into IIRC 24 tets. This
> isn't the most economical splitting but it is very "symmetric" and
> therefore easy to make the split elements line up consistently. This
> splitting also introduces new mid-face nodes, which could be "snapped" to
> the sphere surface as necessary.
>
> Another option would be to configure/build libmesh with the
> --disable-strict-lgpl option and then use the libmesh Tetgen interfaces to
> create a Delaunay mesh of the sphere. If you end up implementing either of
> those, it would be great if you could contribute them back as either
> library code or possibly an augmented miscellaneous_ex6.
>
> Note that libmesh also supports reading several different mesh file
> formats, so if you generate a sphere mesh in e.g. Gmsh, you would be able
> to read it in without doing any major programming yourself...
>
> --
> John
>

Re: [Libmesh-users] building sphere using tetrahedral elements

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

On Thu, Jan 16, 2020 at 1:21 AM Ramakrishnan Thirumalaisamy <
thi...@gm...> wrote:

> Dear libmesh users,
>
> I want to create sphere with tetrahedral elements. I came across this
> function MeshTools::Generation::build_square. But this function supports
> only HEX8/27 for 3D.  Is there any other functions in libmesh that I could
> use to generate sphere with tetrahedral elements?
>

Hi Ramakrishnan,

Your email mentions both spheres and build_square, but I'm assuming what
you're really after is spheres. The implementation doesn't currently exist,
but you could do something similar to what's currently done in the
build_cube() case when Tets are selected. That is, first a mesh of
hexahedra is created and then each hex is split into IIRC 24 tets. This
isn't the most economical splitting but it is very "symmetric" and
therefore easy to make the split elements line up consistently. This
splitting also introduces new mid-face nodes, which could be "snapped" to
the sphere surface as necessary.

Another option would be to configure/build libmesh with the
--disable-strict-lgpl option and then use the libmesh Tetgen interfaces to
create a Delaunay mesh of the sphere. If you end up implementing either of
those, it would be great if you could contribute them back as either
library code or possibly an augmented miscellaneous_ex6.

Note that libmesh also supports reading several different mesh file
formats, so if you generate a sphere mesh in e.g. Gmsh, you would be able
to read it in without doing any major programming yourself...

-- 
John

[Libmesh-users] building sphere using tetrahedral elements

[Ramakrishnan T. <thi...@gm...>]

Dear libmesh users,

I want to create sphere with tetrahedral elements. I came across this
function MeshTools::Generation::build_square. But this function supports
only HEX8/27 for 3D.  Is there any other functions in libmesh that I could
use to generate sphere with tetrahedral elements?

Thanks in advance.

-- 
Regards
Ramakrishnan T.

Re: [Libmesh-users] ALE formulation with moving mesh

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

On Sat, 11 Jan 2020, Bin Liu wrote:

> John mentioned about MOOSE library, which is built on top of
> libmesh. Does MOOSE library make use of
> "libMesh::DifferentiablePhysics" class? It seems MOOSE library can
> deal with the multi-physics problems with dynamic mesh in libmesh
> library quite well. By the way, while sub-dividing an element based
> on the coordinates extracted by "elem->point()", I noticed that the
> truncation error of the coordinates of element nodes is relative
> large. Please correct me, if I am wrong about this.

We do use a generic algorithm in ElemRefinement, so instead of
calculating e.g. new_HEX8_node = sum(two_neighboring_edge_nodes)/2 we
calculate sum(coefficient_i * element_node_i) for all 8 nodes i, which
you'd expect to have four times the floating point error ... but 16
times epsilon is still *really* small, and I believe most of our
Lagrange shape functions actually come out exact at new node points,
in which case there'd be no difference at all in those cases.

> Could it be the reason to affect the convergence rate?  

This seems even more unlikely to be noticeable.  Finite Element
methods work even when you don't perfectly subdivide elements (as some
mesh refinement styles don't, e.g. when smoothly grading into boundary
layers).  An epsilon difference in child element sizes will just mean
that your hmax dropped by .5+epsilon rather than .5, which will mean
an epsilon difference in convergence rates, unless you're specifically
using some superconverence reconstruction trick that depends on
exactly equispaced meshes.

But all that is about what our element subdivision *should* do, not
what it does do.  Could you give a counter-example?

Do note that if you're just printing out elem->point(), unless you've
specifically increased the stream precision() you'll be seeing output
that's much more truncated on the screen than it is in memory.  We
actually had bugs in some of our ASCII I/O formats due to this, years
and years ago, when we forgot to increase precision before writing the
output files.
---
Roy

Re: [Libmesh-users] ALE formulation with moving mesh

[Alexander L. <ale...@gm...>]

MOOSE does not make use of libMesh::DifferentiablePhysics

On Fri, Jan 10, 2020 at 7:39 PM Bin Liu <lea...@ho...> wrote:

> John mentioned about MOOSE library, which is built on top of libmesh. Does
> MOOSE library make use of "libMesh::DifferentiablePhysics" class? It seems
> MOOSE library can deal with the multi-physics problems with dynamic mesh in
> libmesh library quite well. By the way, while sub-dividing an element based
> on the coordinates extracted by "elem->point()", I noticed that the
> truncation error of the coordinates of element nodes is relative large.
> Please correct me, if I am wrong about this. Could it be the reason to
> affect the convergence rate?
>
> Best
> Bin
> ________________________________
> From: Stogner, Roy H <roy...@ic...>
> Sent: Saturday, January 11, 2020 6:41 AM
> To: Bin Liu <lea...@ho...>
> Cc: lib...@li... <
> lib...@li...>
> Subject: Re: [Libmesh-users] ALE formulation with moving mesh
>
>
> On Fri, 10 Jan 2020, Bin Liu wrote:
>
> > I find that libmesh indeed has a class
> > "libMesh::DifferentiablePhysics" to deal with ALE formulation.
>
> On top of what John said, I need to confess that the
> DifferentiablePhysics ALE code was never properly finished.  I got it
> to a state where it was running but didn't seem to be passing
> convergence tests, then the physics people on our project discovered a
> quasi-steady formulation which would work even better than our
> previous unsteay model, and so I didn't have any more time to devote
> to *fixing* the ALE code.
> ---
> Roy
>
> _______________________________________________
> Libmesh-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>

Re: [Libmesh-users] ALE formulation with moving mesh

[Bin L. <lea...@ho...>]

John mentioned about MOOSE library, which is built on top of libmesh. Does MOOSE library make use of "libMesh::DifferentiablePhysics" class? It seems MOOSE library can deal with the multi-physics problems with dynamic mesh in libmesh library quite well. By the way, while sub-dividing an element based on the coordinates extracted by "elem->point()", I noticed that the truncation error of the coordinates of element nodes is relative large. Please correct me, if I am wrong about this. Could it be the reason to affect the convergence rate?

Best
Bin
________________________________
From: Stogner, Roy H <roy...@ic...>
Sent: Saturday, January 11, 2020 6:41 AM
To: Bin Liu <lea...@ho...>
Cc: lib...@li... <lib...@li...>
Subject: Re: [Libmesh-users] ALE formulation with moving mesh


On Fri, 10 Jan 2020, Bin Liu wrote:

> I find that libmesh indeed has a class
> "libMesh::DifferentiablePhysics" to deal with ALE formulation.

On top of what John said, I need to confess that the
DifferentiablePhysics ALE code was never properly finished.  I got it
to a state where it was running but didn't seem to be passing
convergence tests, then the physics people on our project discovered a
quasi-steady formulation which would work even better than our
previous unsteay model, and so I didn't have any more time to devote
to *fixing* the ALE code.
---
Roy

Re: [Libmesh-users] ALE formulation with moving mesh

[Bin L. <lea...@ho...>]

Hi John,
Thanks for your recommendations. I think MOOSE library is a good choice for me to take a look further. So far I am not sure how much I can do inside the framework of MOOSE library. I think I will try to implement codes in MOOSE library first and gain experience of it. My ultimate goals are on applications to solve relatively large scale fluid-structure interaction problems. I will try MOOSE first.

Regards
Bin

________________________________
From: John Peterson <jwp...@gm...>
Sent: Saturday, January 11, 2020 5:45 AM
To: Bin Liu <lea...@ho...>
Cc: lib...@li... <lib...@li...>
Subject: Re: [Libmesh-users] ALE formulation with moving mesh



On Fri, Jan 10, 2020 at 2:34 AM Bin Liu <lea...@ho...<mailto:lea...@ho...>> wrote:
Dear libmesh users,

I am new to this forum and libmesh. I am planning to write a fluid-structure interaction (FSI) solver under arbitrary lagrangian-eulerian (ALE) description. I noticed libmesh is a sophisticated FEM library. There are so many publication based on this library. However, I did not find a publication of monolithic ALE-FSI solver using libmesh library. I understand I can couple it with another software. However I prefer to the monolithic formulation.

I find that libmesh indeed has a class "libMesh::DifferentiablePhysics" to deal with ALE formulation. It will be really good, if there are more helpful examples codes. Could anyone give some suggestions? Is libmesh a good choice to start coding a ALE formulation with dynamic mesh?   Thanks in advance.

Hi Bin Liu,

You may want to look at the FSI work that Cyrill von Planta and collaborators are doing via the MOOSE library, e.g.

https://www.researchgate.net/publication/338446882_Modelling_of_hydro-mechanical_processes_in_heterogeneous_fracture_intersections_using_a_fictitious_domain_method_with_variational_transfer_operators

In addition to that, Boyce Griffith's research group has developed an immersed boundary method with the IBAMR library (https://ibamr.github.io/) which may be of interest to you.

I'm not sure what your ultimate goals are, but I would probably recommend not starting from scratch with libmesh to solve FSI, as it would likely require a lot of work...

--
John

Re: [Libmesh-users] ALE formulation with moving mesh

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

On Fri, 10 Jan 2020, Bin Liu wrote:

> I find that libmesh indeed has a class
> "libMesh::DifferentiablePhysics" to deal with ALE formulation.

On top of what John said, I need to confess that the
DifferentiablePhysics ALE code was never properly finished.  I got it
to a state where it was running but didn't seem to be passing
convergence tests, then the physics people on our project discovered a
quasi-steady formulation which would work even better than our
previous unsteay model, and so I didn't have any more time to devote
to *fixing* the ALE code.
---
Roy

Re: [Libmesh-users] ALE formulation with moving mesh

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

On Fri, Jan 10, 2020 at 2:34 AM Bin Liu <lea...@ho...> wrote:

> Dear libmesh users,
>
> I am new to this forum and libmesh. I am planning to write a
> fluid-structure interaction (FSI) solver under arbitrary
> lagrangian-eulerian (ALE) description. I noticed libmesh is a sophisticated
> FEM library. There are so many publication based on this library. However,
> I did not find a publication of monolithic ALE-FSI solver using libmesh
> library. I understand I can couple it with another software. However I
> prefer to the monolithic formulation.
>
> I find that libmesh indeed has a class "libMesh::DifferentiablePhysics" to
> deal with ALE formulation. It will be really good, if there are more
> helpful examples codes. Could anyone give some suggestions? Is libmesh a
> good choice to start coding a ALE formulation with dynamic mesh?   Thanks
> in advance.
>

Hi Bin Liu,

You may want to look at the FSI work that Cyrill von Planta and
collaborators are doing via the MOOSE library, e.g.

https://www.researchgate.net/publication/338446882_Modelling_of_hydro-mechanical_processes_in_heterogeneous_fracture_intersections_using_a_fictitious_domain_method_with_variational_transfer_operators

In addition to that, Boyce Griffith's research group has developed an
immersed boundary method with the IBAMR library (https://ibamr.github.io/)
which may be of interest to you.

I'm not sure what your ultimate goals are, but I would probably recommend
not starting from scratch with libmesh to solve FSI, as it would likely
require a lot of work...

-- 
John

[Libmesh-users] ALE formulation with moving mesh

[Bin L. <lea...@ho...>]

Dear libmesh users,

I am new to this forum and libmesh. I am planning to write a fluid-structure interaction (FSI) solver under arbitrary lagrangian-eulerian (ALE) description. I noticed libmesh is a sophisticated FEM library. There are so many publication based on this library. However, I did not find a publication of monolithic ALE-FSI solver using libmesh library. I understand I can couple it with another software. However I prefer to the monolithic formulation.

I find that libmesh indeed has a class "libMesh::DifferentiablePhysics" to deal with ALE formulation. It will be really good, if there are more helpful examples codes. Could anyone give some suggestions? Is libmesh a good choice to start coding a ALE formulation with dynamic mesh?   Thanks in advance.

Best regards
Bin

Re: [Libmesh-users] how to compile with installed netcdf?

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

On 2019-12-30 17:26, Stogner, Roy H wrote:
> ----8< snip ----
>> MUMPS is still not detected by libMesh :( .
> 
> Is configure finding your petscconf.h?  Is PETSC_HAVE_MUMPS defined
> there?

I looked into =configure=, and found this:

     $as_echo "#define PETSC_HAVE_MUMPS 1" >>confdefs.h

Then found this in config.status:

     D["PETSC_HAVE_MUMPS"]=" 1"

Then, my config.log shows:

    ----8< snip ----
     configure:6861: mpicxx -c -fPIC -fopenmp -march=amdfam10 
-mtune=generic -fPIC -fopenmp -march=amdfam10 -mtune=generic -O2 
-D_FORTIFY_SOURCE=2 conftest.cpp >&5
     conftest.cpp: In function 'int main()':
     conftest.cpp:18:9: error: 'thisisanerror' was not declared in this 
scope
        18 |         thisisanerror;
           |         ^~~~~~~~~~~~~
     configure:6861: $? = 1
     configure: failed program was:
     | /* confdefs.h */
     ----8< snip ----
     | #define PETSC_HAVE_MUMPS 1
     ----8< snip ----

but I cannot find conftest.cpp. This put a question mark on my face :) .


P.S. If you don't get direct e-mails from me, it's because I can't 
(https://ut.service-now.com/sp?id=kb_article&number=KB0011416)

-------------------------------------------------
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] how to compile with installed netcdf?

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

On 2019-12-30 17:33, Stogner, Roy H wrote:
> ----8<---- snip
> This (plus a bootstrap commit) is now also a PR at
> https://github.com/libMesh/libmesh/pull/2388 - thanks again.

Thanks to you for libMesh. I saw the comments on the PR, and I want to 
share the output of my =configure= (attached). In summary:

    exodus........................... : yes

If you need more information, let me know, although you can see how I 
compile with the repos https://notabug.org/broncodev. In particular, 
remember that I forced the library with =netcdf.m4= (look for this

   #+begin_src autoconf
     LIBS="$LIBS -lnetcdf -L/usr/lib"
     CPPFLAGS="$CPPFLAGS -I/usr/include"
   #+end_src

which may be different in your system), and this in my PKGBUILD (the 
recipe to compile):

   #+begin_SRC bash
     [[ -f /usr/include/netcdf.h ]] && \
         sed -i "s-\(ac_subdirs_all='\)contrib/netcdf/v4-\1-g; 
s-\(subdirs=\"\$subdirs\) contrib/netcdf/v4-\1-g" configure
   #+end_SRC

Happy new year!

-------------------------------------------------
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] Elements sharing common vertex/edge

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

On Wed, 25 Dec 2019, Amneet Bhalla wrote:

> I am working with triangulated surfaces in 3D, and I need to:
>
> 1) Calculate angle-weighted normals at the vertex points, and
>
> 2) Calculate average of normals of two triangles sharing an edge.
>
> For both cases, I think I would need to know all elements sharing a common
> vertex, and two elements sharing a common edge, respectively. Can this
> information extracted from libMesh?

For (1) the answer can be *no* in the case of a distributed mesh with
default ghosting, but if you use a replicated mesh or you have a
ghosting functor that includes point neighbors then you can use
Elem::find_point_neighbors().

For (2) you just use Elem::neighbor_ptr().
---
Roy

Re: [Libmesh-users] how to compile with installed netcdf?

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

On Mon, 30 Dec 2019, ed...@op... wrote:

> I think that I found a way to use my system's netcdf with libMesh (make check 
> gave no errors).

> If you want to try, my recipe is here:
> https://notabug.org/broncodev/libmesh-pkgbuild.git (commit e3d46fc)

This (plus a bootstrap commit) is now also a PR at
https://github.com/libMesh/libmesh/pull/2388 - thanks again.
---
Roy

Re: [Libmesh-users] how to compile with installed netcdf?

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

On Mon, 30 Dec 2019, ed...@op... wrote:

> I think that I found a way to use my system's netcdf with libMesh (make check 
> gave no errors).
>
> - System: Parabola GNU/Linux x86_64 AMD Ryzen 2500
> - PETSc from Git commit 5f77d1e0e5
> - libMesh from Git commit 19706028f
> - a bunch of packagees from repositories (cgns 3.4.0-2, hdf5-openmpi 
> 1.10.5-1, hdf5-openmpi 1.10.5-1, netcdf-openmpi 4.7.1-2, paraview 5.7.0-3, 
> pnetcdf-openmpi 1.12.0-1, python-h5py-openmpi 2.10.0-1, vtk 8.2.0-9, hwloc 
> 2.1.0-2, metis 5.1.0.p7-1, openmp 9.0.0-2, openmpi 4.0.2-3, suitesparse 
> 5.6.0-1, scotch 6.0.6-1)
> - some from AUR's user-contributed packages (fftw-mpi 3.3.8-1, hypre-sm 
> 2.14.0-1, mumps 5.2.1-3, superlu 5.2.1-9)
>
> If you want to try, my recipe is here:
> https://notabug.org/broncodev/libmesh-pkgbuild.git (commit e3d46fc)

I was going to say that there's no way for us to link against an
external netcdf without actually changing our netcdf.m4 file, then I
followed this link to find a patch against our netcdf.m4 file.  So
you're at least on the right track!

I don't have time to check this out myself right now but I'll throw up
a PR with it so we don't lose track of it and so we can see what our
CI thinks of it.  Thanks!

> https://notabug.org/broncodev/petsc-pkgbuild.git (commit 3e9d679)
>
> MUMPS is still not detected by libMesh :( .

Is configure finding your petscconf.h?  Is PETSC_HAVE_MUMPS defined
there?
---
Roy

Re: [Libmesh-users] how to compile with installed netcdf?

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

I think that I found a way to use my system's netcdf with libMesh (make 
check gave no errors).

- System: Parabola GNU/Linux x86_64 AMD Ryzen 2500
- PETSc from Git commit 5f77d1e0e5
- libMesh from Git commit 19706028f
- a bunch of packagees from repositories (cgns 3.4.0-2, hdf5-openmpi 
1.10.5-1, hdf5-openmpi 1.10.5-1, netcdf-openmpi 4.7.1-2, paraview 
5.7.0-3, pnetcdf-openmpi 1.12.0-1, python-h5py-openmpi 2.10.0-1, vtk 
8.2.0-9, hwloc 2.1.0-2, metis 5.1.0.p7-1, openmp 9.0.0-2, openmpi 
4.0.2-3, suitesparse 5.6.0-1, scotch 6.0.6-1)
- some from AUR's user-contributed packages (fftw-mpi 3.3.8-1, hypre-sm 
2.14.0-1, mumps 5.2.1-3, superlu 5.2.1-9)

If you want to try, my recipe is here:
https://notabug.org/broncodev/libmesh-pkgbuild.git (commit e3d46fc)
https://notabug.org/broncodev/petsc-pkgbuild.git (commit 3e9d679)

MUMPS is still not detected by libMesh :( .
Let me know if I did something unwise. Thanks!


On 2019-12-30 10:40, ed...@op... wrote:
> I can still not compile with my system's netcdf. With this code, I can
> compile and run a test:
> 
>   #+begin_SRC cpp
>     #include "netcdf.h"
> 
>     int main(void){
>              static int ncid;
>              nc_create("test.nc", NC_NETCDF4|NC_CLOBBER, &ncid);}
>   #+end_SRC
> 
>   #+begin_SRC bash
>     gcc -Wall -lnetcdf -L/usr/lib -I/usr/include -o run-test test.cpp
>     ./run-test
>     ls test.nc
>   #+end_SRC
> 
>   #+RESULTS:
>   : test.nc
> 
> I added what I thought would be the same to netcdf.m4, but it seems
> that it cannot compile. I show the relevant portions of the attached
> file
> 
>   #+begin_SRC autoconf
>     m4_define([_AX_CXX_COMPILE_NETCDF_preamble],
>     [[
>     @%:@include "netcdf.h"
>     ]])
> 
>     m4_define([_AX_CXX_COMPILE_NETCDF_body],
>     [[
>     static int ncid;
>     nc_create("test.nc", NC_NETCDF4|NC_CLOBBER, &ncid);
>     ]])
>   #+END_SRC
> 
> This message does not show up in the log
> 
>   #+begin_SRC autoconf
>     AS_IF([test "$netcdfincFound" = "no"],
>     [
>     AC_MSG_RESULT(NETCDF header files not found!)
>     enablenetcdf=no;
>     ])
>   #+end_SRC
> 
> So I think that this should work
> 
>   #+BEGIN_SRC autoconf
>     NETCDF_INCLUDE="-I$NETCDF_INC"
>   #+END_SRC
> ---8<--- snip
>   #+begin_SRC autoconf
>     AS_IF([test "x$RPATHFLAG" != "x" && test -d $NETCDF_LIB],
>           [NETCDF_RPATH_FLAGS="${RPATHFLAG}${NETCDF_LIB}"
>            NETCDF_LIBRARY="${RPATHFLAG}${NETCDF_LIB} $NETCDF_LIBRARY"
>           ],
>           [NETCDF_LIBRARY="-L${NETCDF_LIB} -lnetcdf $NETCDF_LIBRARY"])
>     LIBS="$LIBS $NETCDF_LIBRARY"
>     CPPFLAGS="$CPPFLAGS $NETCDF_INCLUDE"
>   #+end_SRC
> 
> But I get the error from here
> 
>   #+begin_SRC autoconf
> 
> AC_LINK_IFELSE([AC_LANG_PROGRAM([_AX_CXX_COMPILE_NETCDF_preamble],[_AX_CXX_COMPILE_NETCDF_body])],
>     [AC_DEFINE(HAVE_NETCDF, 1, [Flag indicating whether the library
> will be compiled with Netcdf support])],
>     [AC_MSG_ERROR(*** Linking a test program against the NETCDF
> libraries failed)])
>   #+end_SRC
> 
> What I find funny is that if I force
> 
>   #+begin_SRC autoconf
>     LIBS="$LIBS -lnetcdf -L/usr/lib"
>     CPPFLAGS="$CPPFLAGS -I/usr/include"
>   #+end_SRC
> 
> then, configure runs well, but still picks up the =contrib/netcdf4=. I
> think that I will live with this. I am sure that there is a silly
> mistake. I hope that it is useful to others. If you want more
> debugging information, let me know.
> 
> On 2019-12-30 00:21, ed...@op... wrote:
>> I attach a patch for netcdf.m4 which can help to use the system's
>> netcdf. Mind you, this is the first autoconf script that I prepare.
>> =make= is currently running. If there is a better solution, let me
>> know. You can also find the file here:
>> https://notabug.org/broncodev/libmesh-pkgbuild and you need to run
>> =autoconf= in the libmesh root directory
>> 
>> On 2019-12-25 13:40, ed...@op... wrote:
>>> Hello,
>>> 
>>> Is there a way to use my system's netcdf instead of the one in the
>>> contrib directory? Thanks!
>> 
>> 
>> -------------------------------------------------
>> 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 mailing list
>> Lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/libmesh-users
> 
> 
> -------------------------------------------------
> 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 mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users

-------------------------------------------------
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] how to compile with installed netcdf?

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

I can still not compile with my system's netcdf. With this code, I can 
compile and run a test:

   #+begin_SRC cpp
     #include "netcdf.h"

     int main(void){
              static int ncid;
              nc_create("test.nc", NC_NETCDF4|NC_CLOBBER, &ncid);}
   #+end_SRC

   #+begin_SRC bash
     gcc -Wall -lnetcdf -L/usr/lib -I/usr/include -o run-test test.cpp
     ./run-test
     ls test.nc
   #+end_SRC

   #+RESULTS:
   : test.nc

I added what I thought would be the same to netcdf.m4, but it seems that 
it cannot compile. I show the relevant portions of the attached file

   #+begin_SRC autoconf
     m4_define([_AX_CXX_COMPILE_NETCDF_preamble],
     [[
     @%:@include "netcdf.h"
     ]])

     m4_define([_AX_CXX_COMPILE_NETCDF_body],
     [[
     static int ncid;
     nc_create("test.nc", NC_NETCDF4|NC_CLOBBER, &ncid);
     ]])
   #+END_SRC

This message does not show up in the log

   #+begin_SRC autoconf
     AS_IF([test "$netcdfincFound" = "no"],
     [
     AC_MSG_RESULT(NETCDF header files not found!)
     enablenetcdf=no;
     ])
   #+end_SRC

So I think that this should work

   #+BEGIN_SRC autoconf
     NETCDF_INCLUDE="-I$NETCDF_INC"
   #+END_SRC
---8<--- snip
   #+begin_SRC autoconf
     AS_IF([test "x$RPATHFLAG" != "x" && test -d $NETCDF_LIB],
           [NETCDF_RPATH_FLAGS="${RPATHFLAG}${NETCDF_LIB}"
            NETCDF_LIBRARY="${RPATHFLAG}${NETCDF_LIB} $NETCDF_LIBRARY"
           ],
           [NETCDF_LIBRARY="-L${NETCDF_LIB} -lnetcdf $NETCDF_LIBRARY"])
     LIBS="$LIBS $NETCDF_LIBRARY"
     CPPFLAGS="$CPPFLAGS $NETCDF_INCLUDE"
   #+end_SRC

But I get the error from here

   #+begin_SRC autoconf
     
AC_LINK_IFELSE([AC_LANG_PROGRAM([_AX_CXX_COMPILE_NETCDF_preamble],[_AX_CXX_COMPILE_NETCDF_body])],
     [AC_DEFINE(HAVE_NETCDF, 1, [Flag indicating whether the library will 
be compiled with Netcdf support])],
     [AC_MSG_ERROR(*** Linking a test program against the NETCDF 
libraries failed)])
   #+end_SRC

What I find funny is that if I force

   #+begin_SRC autoconf
     LIBS="$LIBS -lnetcdf -L/usr/lib"
     CPPFLAGS="$CPPFLAGS -I/usr/include"
   #+end_SRC

then, configure runs well, but still picks up the =contrib/netcdf4=. I 
think that I will live with this. I am sure that there is a silly 
mistake. I hope that it is useful to others. If you want more debugging 
information, let me know.

On 2019-12-30 00:21, ed...@op... wrote:
> I attach a patch for netcdf.m4 which can help to use the system's
> netcdf. Mind you, this is the first autoconf script that I prepare.
> =make= is currently running. If there is a better solution, let me
> know. You can also find the file here:
> https://notabug.org/broncodev/libmesh-pkgbuild and you need to run
> =autoconf= in the libmesh root directory
> 
> On 2019-12-25 13:40, ed...@op... wrote:
>> Hello,
>> 
>> Is there a way to use my system's netcdf instead of the one in the
>> contrib directory? Thanks!
> 
> 
> -------------------------------------------------
> 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 mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users


-------------------------------------------------
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] how to compile with installed netcdf?

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

I attach a patch for netcdf.m4 which can help to use the system's 
netcdf. Mind you, this is the first autoconf script that I prepare. 
=make= is currently running. If there is a better solution, let me know. 
You can also find the file here:
https://notabug.org/broncodev/libmesh-pkgbuild and you need to run 
=autoconf= in the libmesh root directory

On 2019-12-25 13:40, ed...@op... wrote:
> Hello,
> 
> Is there a way to use my system's netcdf instead of the one in the
> contrib directory? Thanks!


-------------------------------------------------
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] Elements sharing common vertex/edge

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

I would prefer to work with libMesh constructs directly.

On Wed, Dec 25, 2019 at 12:42 AM <ed...@op...> wrote:

> On 2019-12-25 07:38, Amneet Bhalla wrote:
> > ---8< snip
> > For both cases, I think I would need to know all elements sharing a
> > common
> > vertex, and two elements sharing a common edge, respectively. Can this
> > information extracted from libMesh? I am reading *.msh triangulated
> > mesh
> > generated by GMSH through libMesh, if this information helps.
>
> I don't know if this is useful, and I am not a libmesh developer, but
> the node information can be extracted from the Gmsh .msh file. I hope
> you get an answer.
>
> -------------------------------------------------
> 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!
>
-- 
--Amneet

[Libmesh-users] how to compile with installed netcdf?

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

Hello,

Is there a way to use my system's netcdf instead of the one in the 
contrib directory? Thanks!

-------------------------------------------------
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] Elements sharing common vertex/edge

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

On 2019-12-25 07:38, Amneet Bhalla wrote:
> ---8< snip
> For both cases, I think I would need to know all elements sharing a 
> common
> vertex, and two elements sharing a common edge, respectively. Can this
> information extracted from libMesh? I am reading *.msh triangulated 
> mesh
> generated by GMSH through libMesh, if this information helps.

I don't know if this is useful, and I am not a libmesh developer, but 
the node information can be extracted from the Gmsh .msh file. I hope 
you get an answer.

-------------------------------------------------
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] Elements sharing common vertex/edge

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

Hi Folks,

I am working with triangulated surfaces in 3D, and I need to:

1) Calculate angle-weighted normals at the vertex points, and

2) Calculate average of normals of two triangles sharing an edge.

For both cases, I think I would need to know all elements sharing a common
vertex, and two elements sharing a common edge, respectively. Can this
information extracted from libMesh? I am reading *.msh triangulated mesh
generated by GMSH through libMesh, if this information helps.

Thanks,
—Amneet
-- 
--Amneet