libmesh-users — General information for libmesh users

[Libmesh-users] question about reading mesh from Gmesh

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

Dear libmesh developers,

I have a simple gmesh *.geo script where I create a 1D mesh.

There I have the following:

Physical Line("p") = {5};
Physical Line("n") = {6};


Physical Point("p_contact") = {1};
Physical Point("n_contact") = {3};


When I read the mesh, then the names of physical lines are read by 
GmshIO class and are accessible via mesh.get_subdomain_name_map();

Is it possible to access names of the physical points? Or, more 
generally, are the names of physical elements of lower dimensions are 
read by libmesh?

Thank you,

Michael.

Re: [Libmesh-users] HDF5 compatibility

[David K. <dav...@ak...>]

FYI, we use HDF5 version 1.10.2 released on 2018-03-29. This works fine
with the netCDF bundled with libMesh for us.

David


On Thu, Jul 4, 2019 at 10:02 AM Alexander Lindsay <ale...@gm...>
wrote:

> I was able to successfully run using HDF5 version 1.8.20. Based on the
> issue I referenced, I wonder whether 1.10.1 and 1.10.2 may also work.
>
> On Wed, Jul 3, 2019 at 5:57 PM Alexander Lindsay <ale...@gm...
> >
> wrote:
>
> > Do we know what version of HDF5 is compatabile with our current netCDF
> > release (4.6.2)? There is some discussion on compatability here:
> > https://github.com/Unidata/netcdf-c/issues/951. I've configured libmesh
> > with the options: --enable-hdf5 and --with-hdf5 where I point to a 1.10.5
> > hdf5 version. However, when I try to run MOOSE's simple_diffusion test, I
> > get this error:
> >
> > Exodus Library Error: [ex_create]
> > Error: file create failed for simple_diffusion_out.e in NETCDF4 and
> > CLOBBER mode.
> > This library probably does not support netcdf-4 files.
> >     exerrval = 13
> > Error creating ExodusII mesh file.
> > Stack frames: 18
> > 0: 0   libmesh_dbg.0.dylib                 0x0000000106c691ba
> > libMesh::print_trace(std::__1::basic_ostream<char,
> > std::__1::char_traits<char> >&) + 458
> > 1: 1   libmesh_dbg.0.dylib                 0x0000000106c5fe6e
> > libMesh::MacroFunctions::report_error(char const*, int, char const*, char
> > const*) + 222
> > 2: 2   libmesh_dbg.0.dylib                 0x0000000107223d9c
> > libMesh::ExodusII_IO_Helper::create(std::__1::basic_string<char,
> > std::__1::char_traits<char>, std::__1::allocator<char> >) + 444
> > 3: 3   libmesh_dbg.0.dylib                 0x000000010720eeab
> >
> libMesh::ExodusII_IO::write_nodal_data_common(std::__1::basic_string<char,
> > std::__1::char_traits<char>, std::__1::allocator<char> >,
> > std::__1::vector<std::__1::basic_string<char,
> std::__1::char_traits<char>,
> > std::__1::allocator<char> >,
> > std::__1::allocator<std::__1::basic_string<char,
> > std::__1::char_traits<char>, std::__1::allocator<char> > > > const&,
> bool)
> > + 315
> > 4: 4   libmesh_dbg.0.dylib                 0x000000010720e8c4
> > libMesh::ExodusII_IO::write_nodal_data(std::__1::basic_string<char,
> > std::__1::char_traits<char>, std::__1::allocator<char> > const&,
> > std::__1::vector<double, std::__1::allocator<double> > const&,
> > std::__1::vector<std::__1::basic_string<char,
> std::__1::char_traits<char>,
> > std::__1::allocator<char> >,
> > std::__1::allocator<std::__1::basic_string<char,
> > std::__1::char_traits<char>, std::__1::allocator<char> > > > const&) +
> 276
> > 5: 5   libmesh_dbg.0.dylib                 0x00000001073e525f
> >
> libMesh::MeshOutput<libMesh::MeshBase>::write_equation_systems(std::__1::basic_string<char,
> > std::__1::char_traits<char>, std::__1::allocator<char> > const&,
> > libMesh::EquationSystems const&,
> std::__1::set<std::__1::basic_string<char,
> > std::__1::char_traits<char>, std::__1::allocator<char> >,
> > std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>,
> > std::__1::allocator<char> > >,
> > std::__1::allocator<std::__1::basic_string<char,
> > std::__1::char_traits<char>, std::__1::allocator<char> > > > const*) +
> 1551
> > 6: 6   libmesh_dbg.0.dylib                 0x000000010720f8b6
> > libMesh::ExodusII_IO::write_timestep(std::__1::basic_string<char,
> > std::__1::char_traits<char>, std::__1::allocator<char> > const&,
> > libMesh::EquationSystems const&, int, double,
> > std::__1::set<std::__1::basic_string<char, std::__1::char_traits<char>,
> > std::__1::allocator<char> >, std::__1::less<std::__1::basic_string<char,
> > std::__1::char_traits<char>, std::__1::allocator<char> > >,
> > std::__1::allocator<std::__1::basic_string<char,
> > std::__1::char_traits<char>, std::__1::allocator<char> > > > const*) + 86
> > 7: 7   libmoose-dbg.0.dylib                0x00000001021df9a0
> > Exodus::outputNodalVariables() + 576
> > 8: 8   libmoose-dbg.0.dylib                0x00000001021c2b4d
> > AdvancedOutput::output(MooseEnumItem const&) + 157
> > 9: 9   libmoose-dbg.0.dylib                0x00000001021e0747
> > Exodus::output(MooseEnumItem const&) + 391
> > 10: 10  libmoose-dbg.0.dylib                0x00000001021eacd8
> > OversampleOutput::outputStep(MooseEnumItem const&) + 520
> > 11: 11  libmoose-dbg.0.dylib                0x00000001021e9387
> > OutputWarehouse::outputStep(MooseEnumItem) + 183
> > 12: 12  libmoose-dbg.0.dylib                0x0000000101ace8e7
> > FEProblemBase::outputStep(MooseEnumItem) + 279
> >
> > I'm wondering what's going on...
> >
>
> _______________________________________________
> Libmesh-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>

[Libmesh-users] Normalization for nonlinear solver

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

Hi all,

I have a system of equations which differ by orders of magnitudes.
They are solved with PETSc SNES, and I am facing converging issues.

Do you know of any facility in libmesh/PETSc to normalize/precondition
these equations? I can, of course, do that manually... is that the way to
go?

Thanks
Renato

[Libmesh-users] Opening at Align Technology for engineers with libmesh experience

[Yuxiang W. <yw...@vi...>]

Dear all,

First of all, sorry for the spam. I am not sure whether this list is
appropriate for such postings, and please do let me know if it is not.

Here at Align Technology, San Jose, CA, USA, we have an opening looking for
engineers optimally with libmesh experiences. Candidates with
elastodynamics or general solid mechanics experience would be a great fit;
additive manufacturing experience would be a plus.

The job post is here: https://jobs.jobvite.com/align-tech/job/ortjafw7.
Note that on the webpage it did not mention libmesh nor elastodynamics
although those are part of the responsibilities.

Let me know if you are interested! Feel free to apply directly or shoot me
an email.

Best,
Shawn

-- 
Yuxiang "Shawn" Wang, PhD
yw...@vi...
+1 (434) 284-0836

Re: [Libmesh-users] HDF5 compatibility

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

I was able to successfully run using HDF5 version 1.8.20. Based on the
issue I referenced, I wonder whether 1.10.1 and 1.10.2 may also work.

On Wed, Jul 3, 2019 at 5:57 PM Alexander Lindsay <ale...@gm...>
wrote:

> Do we know what version of HDF5 is compatabile with our current netCDF
> release (4.6.2)? There is some discussion on compatability here:
> https://github.com/Unidata/netcdf-c/issues/951. I've configured libmesh
> with the options: --enable-hdf5 and --with-hdf5 where I point to a 1.10.5
> hdf5 version. However, when I try to run MOOSE's simple_diffusion test, I
> get this error:
>
> Exodus Library Error: [ex_create]
> Error: file create failed for simple_diffusion_out.e in NETCDF4 and
> CLOBBER mode.
> This library probably does not support netcdf-4 files.
>     exerrval = 13
> Error creating ExodusII mesh file.
> Stack frames: 18
> 0: 0   libmesh_dbg.0.dylib                 0x0000000106c691ba
> libMesh::print_trace(std::__1::basic_ostream<char,
> std::__1::char_traits<char> >&) + 458
> 1: 1   libmesh_dbg.0.dylib                 0x0000000106c5fe6e
> libMesh::MacroFunctions::report_error(char const*, int, char const*, char
> const*) + 222
> 2: 2   libmesh_dbg.0.dylib                 0x0000000107223d9c
> libMesh::ExodusII_IO_Helper::create(std::__1::basic_string<char,
> std::__1::char_traits<char>, std::__1::allocator<char> >) + 444
> 3: 3   libmesh_dbg.0.dylib                 0x000000010720eeab
> libMesh::ExodusII_IO::write_nodal_data_common(std::__1::basic_string<char,
> std::__1::char_traits<char>, std::__1::allocator<char> >,
> std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>,
> std::__1::allocator<char> >,
> std::__1::allocator<std::__1::basic_string<char,
> std::__1::char_traits<char>, std::__1::allocator<char> > > > const&, bool)
> + 315
> 4: 4   libmesh_dbg.0.dylib                 0x000000010720e8c4
> libMesh::ExodusII_IO::write_nodal_data(std::__1::basic_string<char,
> std::__1::char_traits<char>, std::__1::allocator<char> > const&,
> std::__1::vector<double, std::__1::allocator<double> > const&,
> std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>,
> std::__1::allocator<char> >,
> std::__1::allocator<std::__1::basic_string<char,
> std::__1::char_traits<char>, std::__1::allocator<char> > > > const&) + 276
> 5: 5   libmesh_dbg.0.dylib                 0x00000001073e525f
> libMesh::MeshOutput<libMesh::MeshBase>::write_equation_systems(std::__1::basic_string<char,
> std::__1::char_traits<char>, std::__1::allocator<char> > const&,
> libMesh::EquationSystems const&, std::__1::set<std::__1::basic_string<char,
> std::__1::char_traits<char>, std::__1::allocator<char> >,
> std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>,
> std::__1::allocator<char> > >,
> std::__1::allocator<std::__1::basic_string<char,
> std::__1::char_traits<char>, std::__1::allocator<char> > > > const*) + 1551
> 6: 6   libmesh_dbg.0.dylib                 0x000000010720f8b6
> libMesh::ExodusII_IO::write_timestep(std::__1::basic_string<char,
> std::__1::char_traits<char>, std::__1::allocator<char> > const&,
> libMesh::EquationSystems const&, int, double,
> std::__1::set<std::__1::basic_string<char, std::__1::char_traits<char>,
> std::__1::allocator<char> >, std::__1::less<std::__1::basic_string<char,
> std::__1::char_traits<char>, std::__1::allocator<char> > >,
> std::__1::allocator<std::__1::basic_string<char,
> std::__1::char_traits<char>, std::__1::allocator<char> > > > const*) + 86
> 7: 7   libmoose-dbg.0.dylib                0x00000001021df9a0
> Exodus::outputNodalVariables() + 576
> 8: 8   libmoose-dbg.0.dylib                0x00000001021c2b4d
> AdvancedOutput::output(MooseEnumItem const&) + 157
> 9: 9   libmoose-dbg.0.dylib                0x00000001021e0747
> Exodus::output(MooseEnumItem const&) + 391
> 10: 10  libmoose-dbg.0.dylib                0x00000001021eacd8
> OversampleOutput::outputStep(MooseEnumItem const&) + 520
> 11: 11  libmoose-dbg.0.dylib                0x00000001021e9387
> OutputWarehouse::outputStep(MooseEnumItem) + 183
> 12: 12  libmoose-dbg.0.dylib                0x0000000101ace8e7
> FEProblemBase::outputStep(MooseEnumItem) + 279
>
> I'm wondering what's going on...
>

[Libmesh-users] HDF5 compatibility

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

Do we know what version of HDF5 is compatabile with our current netCDF
release (4.6.2)? There is some discussion on compatability here:
https://github.com/Unidata/netcdf-c/issues/951. I've configured libmesh
with the options: --enable-hdf5 and --with-hdf5 where I point to a 1.10.5
hdf5 version. However, when I try to run MOOSE's simple_diffusion test, I
get this error:

Exodus Library Error: [ex_create]
Error: file create failed for simple_diffusion_out.e in NETCDF4 and CLOBBER
mode.
This library probably does not support netcdf-4 files.
    exerrval = 13
Error creating ExodusII mesh file.
Stack frames: 18
0: 0   libmesh_dbg.0.dylib                 0x0000000106c691ba
libMesh::print_trace(std::__1::basic_ostream<char,
std::__1::char_traits<char> >&) + 458
1: 1   libmesh_dbg.0.dylib                 0x0000000106c5fe6e
libMesh::MacroFunctions::report_error(char const*, int, char const*, char
const*) + 222
2: 2   libmesh_dbg.0.dylib                 0x0000000107223d9c
libMesh::ExodusII_IO_Helper::create(std::__1::basic_string<char,
std::__1::char_traits<char>, std::__1::allocator<char> >) + 444
3: 3   libmesh_dbg.0.dylib                 0x000000010720eeab
libMesh::ExodusII_IO::write_nodal_data_common(std::__1::basic_string<char,
std::__1::char_traits<char>, std::__1::allocator<char> >,
std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char> >,
std::__1::allocator<std::__1::basic_string<char,
std::__1::char_traits<char>, std::__1::allocator<char> > > > const&, bool)
+ 315
4: 4   libmesh_dbg.0.dylib                 0x000000010720e8c4
libMesh::ExodusII_IO::write_nodal_data(std::__1::basic_string<char,
std::__1::char_traits<char>, std::__1::allocator<char> > const&,
std::__1::vector<double, std::__1::allocator<double> > const&,
std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char> >,
std::__1::allocator<std::__1::basic_string<char,
std::__1::char_traits<char>, std::__1::allocator<char> > > > const&) + 276
5: 5   libmesh_dbg.0.dylib                 0x00000001073e525f
libMesh::MeshOutput<libMesh::MeshBase>::write_equation_systems(std::__1::basic_string<char,
std::__1::char_traits<char>, std::__1::allocator<char> > const&,
libMesh::EquationSystems const&, std::__1::set<std::__1::basic_string<char,
std::__1::char_traits<char>, std::__1::allocator<char> >,
std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char> > >,
std::__1::allocator<std::__1::basic_string<char,
std::__1::char_traits<char>, std::__1::allocator<char> > > > const*) + 1551
6: 6   libmesh_dbg.0.dylib                 0x000000010720f8b6
libMesh::ExodusII_IO::write_timestep(std::__1::basic_string<char,
std::__1::char_traits<char>, std::__1::allocator<char> > const&,
libMesh::EquationSystems const&, int, double,
std::__1::set<std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char> >, std::__1::less<std::__1::basic_string<char,
std::__1::char_traits<char>, std::__1::allocator<char> > >,
std::__1::allocator<std::__1::basic_string<char,
std::__1::char_traits<char>, std::__1::allocator<char> > > > const*) + 86
7: 7   libmoose-dbg.0.dylib                0x00000001021df9a0
Exodus::outputNodalVariables() + 576
8: 8   libmoose-dbg.0.dylib                0x00000001021c2b4d
AdvancedOutput::output(MooseEnumItem const&) + 157
9: 9   libmoose-dbg.0.dylib                0x00000001021e0747
Exodus::output(MooseEnumItem const&) + 391
10: 10  libmoose-dbg.0.dylib                0x00000001021eacd8
OversampleOutput::outputStep(MooseEnumItem const&) + 520
11: 11  libmoose-dbg.0.dylib                0x00000001021e9387
OutputWarehouse::outputStep(MooseEnumItem) + 183
12: 12  libmoose-dbg.0.dylib                0x0000000101ace8e7
FEProblemBase::outputStep(MooseEnumItem) + 279

I'm wondering what's going on...

[Libmesh-users] question about nedelec elements

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

Dear Libmesh developers,

I have a system with Nedelec elements.

I would like to order the DOFs in a particular way. What would be the 
right way to do it?

Thank you,

Michael.

[Libmesh-users] Fwd: MOOSE Developer Posting

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

libMesh users,

The MOOSE Team is hiring! We are looking for top candidates to join our
high-energy team when we make our move to the new Collaborative Computing
Center building opening this fall:
https://inl.gov/article/new-inl-computing-facilities-an-investment-in-idahos-future/

Please take a look at the qualifications through the link below and apply.
Please feel free to share this posting with colleagues, associates, or
friends that may be interested in working with us:
https://inl.taleo.net/careersection/inl_external/jobdetail.ftl?job=13489&tz=GMT-06%3A00&tzname=America%2FDenver

or Navigate to this posting through the https://inlcareers.inl.gov website.
Posting #13489.

Re: [Libmesh-users] About moving mesh and redistributing internal mesh

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

Hmm it sounds like if this works as intended, the LaplaceMeshSmoother could be used for some of our ALE calculations to avoid problems like negative Jacobians. Whenever we’ve talked about remeshing in MOOSE we’ve discussed it as if we’ll need mesh generation software like gmshs new C++ API or triangle or tetgen. Seems like we could get by with this existing capability in a lot of our cases...

> On Jun 21, 2019, at 9:12 AM, John Peterson <jwp...@gm...> wrote:
> 
>> On Fri, Jun 21, 2019 at 9:36 AM 서승진 <tjt...@gm...> wrote:
>> 
>> I tried to use the smoother after reading your email, and  it seems that
>> the LaplaceMeshSmoother is quitely similar with smooth function in
>> MeshTools::Modification namespace.
>> 
>> After trying this, I found a new problem.
>> 
>> As you said, boundary nodes are not moved.
>> 
>> However, internal nodes escape from its domain, and as you said, it seems
>> that they ingnore the boundary nodes...
>> 
> 
> Are you still running the smoother for 1000 iterations as in the original
> code snippet you posted? That may be causing an issue, as I don't think
> I've ever tested Laplace smoothing for more than about 2 iterations. Note
> that even though boundary nodes are not moved, they should still be
> accounted for in the "averaging" process of the smoother, and therefore
> nodes should not be able to go outside the domain. Theoretically I think
> it's possible for Laplace mesh smoothing to send points outside the domain
> for non-convex geometries, though off the top of my head I can't really
> construct a case where this would happen for Quad4s... and I don't think
> you have a non-convex domain (?) so I'm not really clear on how your
> internal nodes are escaping.
> 
> --
> John
> 
> _______________________________________________
> Libmesh-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] About moving mesh and redistributing internal mesh

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

On Fri, Jun 21, 2019 at 9:36 AM 서승진 <tjt...@gm...> wrote:

>  I tried to use the smoother after reading your email, and  it seems that
> the LaplaceMeshSmoother is quitely similar with smooth function in
> MeshTools::Modification namespace.
>
> After trying this, I found a new problem.
>
>  As you said, boundary nodes are not moved.
>
>  However, internal nodes escape from its domain, and as you said, it seems
> that they ingnore the boundary nodes...
>

Are you still running the smoother for 1000 iterations as in the original
code snippet you posted? That may be causing an issue, as I don't think
I've ever tested Laplace smoothing for more than about 2 iterations. Note
that even though boundary nodes are not moved, they should still be
accounted for in the "averaging" process of the smoother, and therefore
nodes should not be able to go outside the domain. Theoretically I think
it's possible for Laplace mesh smoothing to send points outside the domain
for non-convex geometries, though off the top of my head I can't really
construct a case where this would happen for Quad4s... and I don't think
you have a non-convex domain (?) so I'm not really clear on how your
internal nodes are escaping.

--
John

Re: [Libmesh-users] About moving mesh and redistributing internal mesh

[서승진 <tjt...@gm...>]

 I tried to use the smoother after reading your email, and  it seems that
the LaplaceMeshSmoother is quitely similar with smooth function in
MeshTools::Modification namespace.

After trying this, I found a new problem.

 As you said, boundary nodes are not moved.

 However, internal nodes escape from its domain, and as you said, it seems
that they ingnore the boundary nodes...

 My object is changed from; (smoothing mesh without moving boundary node
--> smooth without escaping of internal nodes)


Thanks for your answer
Seungjin Seo

2019년 6월 21일 (금) 오후 10:21, John Peterson <jwp...@gm...>님이 작성:

>
>
> On Thu, Jun 20, 2019 at 2:23 AM 서승진 <tjt...@gm...> wrote:
>
>> Hi.
>>
>> I re-send my question (because no enter is recognized in my previous
>> question)
>>
>> I am currently making a code which can treat moving mesh problem.
>>
>> I used GmshIO to construct mesh object, andI made a function to move
>> boundary nodes in one boundary, as given amount (of growth).
>>
>> The thing what I want to do now is redistribute internal mesh to prevent
>> negative jacobian from twisted nodes after the intended movement.
>>
>> In here, I want to fix the position of bounday nodes, so I just want to
>> redistribute internal nodes only.
>>
>> I have used the MeshTools::Modification::smooth() function to redistribute
>> the nodes, but it seems that this use "averaged position between nodes".
>>
>> So this lead the unintended movement of boundary nodes after their
>> intended movement (when I used smooth function)
>>
>> Is there any possible way to solve this kind of problem?
>>
>
>
> > MeshTools::Modification::smooth(mesh, 1000, 0);
>
> Can you try calling the LaplaceMeshSmoother directly? It is not supposed
> to move boundary nodes. I just looked at the source code of
> MeshTools::Modification::smooth(), which I originally had just assumed was
> calling the LaplaceMeshSmoother, but it seems to be doing something else,
> and explicitly takes into account refinement but seems to ignore boundary
> nodes.
>
> --
> John
>

Re: [Libmesh-users] About moving mesh and redistributing internal mesh

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

On Thu, Jun 20, 2019 at 2:23 AM 서승진 <tjt...@gm...> wrote:

> Hi.
>
> I re-send my question (because no enter is recognized in my previous
> question)
>
> I am currently making a code which can treat moving mesh problem.
>
> I used GmshIO to construct mesh object, andI made a function to move
> boundary nodes in one boundary, as given amount (of growth).
>
> The thing what I want to do now is redistribute internal mesh to prevent
> negative jacobian from twisted nodes after the intended movement.
>
> In here, I want to fix the position of bounday nodes, so I just want to
> redistribute internal nodes only.
>
> I have used the MeshTools::Modification::smooth() function to redistribute
> the nodes, but it seems that this use "averaged position between nodes".
>
> So this lead the unintended movement of boundary nodes after their
> intended movement (when I used smooth function)
>
> Is there any possible way to solve this kind of problem?
>


> MeshTools::Modification::smooth(mesh, 1000, 0);

Can you try calling the LaplaceMeshSmoother directly? It is not supposed to
move boundary nodes. I just looked at the source code of
MeshTools::Modification::smooth(), which I originally had just assumed was
calling the LaplaceMeshSmoother, but it seems to be doing something else,
and explicitly takes into account refinement but seems to ignore boundary
nodes.

-- 
John

[Libmesh-users] About moving mesh and redistributing internal mesh

[서승진 <tjt...@gm...>]

Hi.

I re-send my question (because no enter is recognized in my previous
question)

I am currently making a code which can treat moving mesh problem.

I used GmshIO to construct mesh object, andI made a function to move
boundary nodes in one boundary, as given amount (of growth).

The thing what I want to do now is redistribute internal mesh to prevent
negative jacobian from twisted nodes after the intended movement.

In here, I want to fix the position of bounday nodes, so I just want to
redistribute internal nodes only.

I have used the MeshTools::Modification::smooth() function to redistribute
the nodes, but it seems that this use "averaged position between nodes".

So this lead the unintended movement of boundary nodes after their
intended movement (when I used smooth function)

Is there any possible way to solve this kind of problem?




More information for my case;  Assume that there is a 2D rectanguler mesh
file from Gmsh. It will contain;
   4 point for edge ((0,0), (1,0), (1,1), and (0,1))
   4 bounadry id (left = 1, bottom = 2, right = 3, top = 4)
   1 domain id (surface = 1) My object is to move the boundary nodes in
"right boundary" , and redistribute internal nodes without boundary nodes

>From the mesh file, I make mesh object by using
"GmshIO(mesh).read("meshfile_name.msh");"

and by using followed function, I write the a function, which includes
followed contents;

void Function(Mesh & mesh)
{
  MeshBase::element_iterator el = mesh.level_elements_begin(0);
  MeshBase::element_iterator end = mesh.level_elements_end(0);
  for (; el != end; ++el)
  {
      const Elem* elem = *el;
      std::vector<boundary_id_type> bc_ids;
      for (unsigned int s = 0; s < elem->n_neighbors(); s++)
       {
             if (elem->neighbor(s) == NULL)
              {
                   mesh.get_boundary_info().boundary_ids (elem, s,
bc_ids);
                    for (std::vector<boundary_id_type>::const_iterator b =
bc_ids.begin(0; b != bc_ids.end(); ++b)
                    {
                           const boundary id_type bc_id = *b;
                            if (bc_id == 3) // Right
boundary
                           {
                                  std::unique_ptr<Elem> side
(elem->build_side(0));
                                  Node* node0 =
side->get_node(0);
                                  const unsigned int id0 =
node0->id();
                                  Point point0 = *static_cast<const Point
*>(node0);
                                  thickness_at_height =
Function_to_calculate_thickness_at_height(point0(1)); // This function will
return the amount of movement at each height
                                  mesh.node(id0) =
Point(thickness_at_height, point0(1), point0(2));
                            }
                    }
               }
        }
   }
    MeshTools::Modification::smooth(mesh, 1000, 0);
}
Thanks for reading my question.

Best regards;
Seungjin Seo.

[Libmesh-users] About moving mesh and redistributing internal mesh

[<mis...@ka...>]

Hi. I am currently making a code which can treat moving mesh problem.I used GmshIO to construct mesh object, andI made a function to move boundary nodes in one boundary, as given amount (of growth). The thing what I want to do now is redistribute internal mesh to prevent negative jacobian from twisted nodes after the intended movement. In here, I want to fix the position of bounday nodes, so I just want to redistribute internal nodes only. I have used the MeshTools::Modification::smooth() function to redistribute the nodes, but it seems that this use "averaged position between nodes".So this lead the unintended movement of boundary nodes after their intended movement (when I used smooth function) Is there any possible way to solve this kind of problem? More information for my case;  Assume that there is a 2D rectanguler mesh file from Gmsh. It will contain;  4 point for edge ((0,0), (1,0), (1,1), and (0,1))  4 bounadry id (left = 1, bottom = 2, right = 3, top = 4)  1 domain id (surface = 1) My object is to move the boundary nodes in "right boundary" , and redistribute internal nodes without boundary nodes From the mesh file, I make mesh object by using   "GmshIO(mesh).read("meshfile_name.msh");" and by using followed function, I write the a function, which includes followed contents;void Function(Mesh & mesh){  MeshBase::element_iterator el = mesh.level_elements_begin(0);  MeshBase::element_iterator end = mesh.level_elements_end(0);   for (; el != end; ++el)  {     const Elem* elem = *el;     std::vector<boundary_id_type> bc_ids;     for (unsigned int s = 0; s < elem->n_neighbors(); s++)     {        if (elem->neighbor(s) == NULL)        {           mesh.get_boundary_info().boundary_ids (elem, s, bc_ids);           for (std::vector<boundary_id_type>::const_iterator b = bc_ids.begin(0; b != bc_ids.end(); ++b)           {               const boundary id_type bc_id = *b;               if (bc_id == 3) // Right boundary                {                   std::unique_ptr<Elem> side (elem->build_side(0));                   Node* node0 = side->get_node(0);                   const unsigned int id0 = node0->id();                   Point point0 = *static_cast<const Point *>(node0);                   thickness_at_height = Function_to_calculate_thickness_at_height(point0(1)); // This function will return the amount of movement at each height                   mesh.node(id0) = Point(thickness_at_height, point0(1), point0(2));                }            }         }      }    }   MeshTools::Modification::smooth(mesh, 1000, 0); } Thanks for reading my question.Best regards;Seungjin Seo.  

[Libmesh-users] Accessing shared nodes between processors

[Viviana P. B. <vpa...@uc...>]

Hello,

I have a LinearImplicitSystem with a mesh imported from an Exodus file.
When assembling the system matrix and rhs, I proceed according to your
examples iterating over the elements with the active_local_elements
iterator.

I want to do some calculations in between time steps using the solution
vector and iterating over the nodes. When running in parallel, depending on
the iterator, I obtain inconsistent results. Specifically, the nodes that
are shared between processors don't have numerical value assigned to them
which results in a strange region that propagates error (pic attached when
running with 2 proc).

I have tried using different iterators: local_nodes, active_local_nodes,
pid_nodes, and iterating over the list obtained
from dof_map.get_send_list(). The results are inconsistent and never match
the conditions when running in 1 processor. Is there any way I can access
the list of nodes that comprise that boundary? Should I be using some
function from the Parallel communicator?

Thanks!
Best,
Viviana.

 --
*Viviana Palacio Betancur*
PhD Candidate || Graduate Research Assistant || de Pablo group
<https://pme.uchicago.edu/de_pablo_lab/>
Office: ERC 351 || Email: vpa...@uc... || PME @ UChicago
Phone: +1 312 889 2434

Re: [Libmesh-users] TransientSystem::old_solution vs TransientSystem::old_local_solution

[Yuxiang W. <yw...@vi...>]

Thank you John for the clarification and the pointer! I will read more into
numeric_vector.h.

Have a great one,
Shawn

On Mon, Jun 17, 2019 at 6:05 AM John Peterson <jwp...@gm...> wrote:

>
>
> On Mon, Jun 10, 2019 at 12:52 AM Yuxiang Wang <yw...@vi...> wrote:
>
>> Dear all,
>>
>> Quick question - in using the TransientSystem::old_solution vs
>> TransientSystem::old_local_solution, I noticed that the former seems to be
>> exactly the latter plus two size checks. Therefore, can I simply use the
>> latter (old_local_solution) if I am sure that the DOF number is correct?
>>
>
> I think the main difference between old_solution and old_local_solution is
> that the former is of type PARALLEL while the latter is of type GHOSTED
> (see numeric_vector.h for some description of the different types). The
> latter should be used when doing assembly.
>
> --
> John
>


-- 
Yuxiang "Shawn" Wang, PhD
yw...@vi...
+1 (434) 284-0836

Re: [Libmesh-users] TransientSystem::old_solution vs TransientSystem::old_local_solution

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

On Mon, Jun 10, 2019 at 12:52 AM Yuxiang Wang <yw...@vi...> wrote:

> Dear all,
>
> Quick question - in using the TransientSystem::old_solution vs
> TransientSystem::old_local_solution, I noticed that the former seems to be
> exactly the latter plus two size checks. Therefore, can I simply use the
> latter (old_local_solution) if I am sure that the DOF number is correct?
>

I think the main difference between old_solution and old_local_solution is
that the former is of type PARALLEL while the latter is of type GHOSTED
(see numeric_vector.h for some description of the different types). The
latter should be used when doing assembly.

-- 
John

Re: [Libmesh-users] FEBase object fails to calculate values

[Nathan A. M. <Nat...@co...>]

Thanks John. That seems to have done the trick.

On Wed, Jun 12, 2019 at 4:00 PM John Peterson <jwp...@gm...> wrote:

>
>
> On Wed, Jun 12, 2019 at 4:58 PM John Peterson <jwp...@gm...>
> wrote:
>
>>
>>
>> On Wed, Jun 12, 2019 at 4:38 PM Nathan Andrew Miller <
>> Nat...@co...> wrote:
>>
>>> I'm trying to compute the xyz, JxW, and other values at arbitrary points
>>> for a FEBase object during the evaluation of a MOOSE UserObject. I
>>> implemented the following in code:
>>>
>>> ```
>>> //Create a vector of points
>>> std::vector< Point > cell_points;
>>>
>>> ...things to fill cell_points...
>>>
>>> //Create a vector of ones (the weights)
>>> ones = std::vector< double > (cell_points.size(), 1);
>>>
>>> std::unique_ptr< libMesh::FEBase > fe(
>>> libMesh::FEBase::build(_mesh.dimension(),
>>> libMesh::FEType(_current_elem->default_order())));
>>>
>>> fe->reinit(_current_elem, &cell_points, &ones);
>>>
>>>
>> You have to pre-request that the xyz values be computed before you call
>> fe->reinit. So put the following line:
>>
>>
>>> std::vector< Point > xyz = fe->get_xyz();
>>>
>>
>> before the reinit() call and it should work.
>>
>
> Oh, and be sure to get a *reference*
>
> std::vector< Point > & xyz = fe->get_xyz();
>
> because it's going to be filled/changed as you reinit more elements later.
> In the code you posted you are making a copy...
>
> --
> John
>

Re: [Libmesh-users] FEBase object fails to calculate values

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

On Wed, Jun 12, 2019 at 4:58 PM John Peterson <jwp...@gm...> wrote:

>
>
> On Wed, Jun 12, 2019 at 4:38 PM Nathan Andrew Miller <
> Nat...@co...> wrote:
>
>> I'm trying to compute the xyz, JxW, and other values at arbitrary points
>> for a FEBase object during the evaluation of a MOOSE UserObject. I
>> implemented the following in code:
>>
>> ```
>> //Create a vector of points
>> std::vector< Point > cell_points;
>>
>> ...things to fill cell_points...
>>
>> //Create a vector of ones (the weights)
>> ones = std::vector< double > (cell_points.size(), 1);
>>
>> std::unique_ptr< libMesh::FEBase > fe(
>> libMesh::FEBase::build(_mesh.dimension(),
>> libMesh::FEType(_current_elem->default_order())));
>>
>> fe->reinit(_current_elem, &cell_points, &ones);
>>
>>
> You have to pre-request that the xyz values be computed before you call
> fe->reinit. So put the following line:
>
>
>> std::vector< Point > xyz = fe->get_xyz();
>>
>
> before the reinit() call and it should work.
>

Oh, and be sure to get a *reference*

std::vector< Point > & xyz = fe->get_xyz();

because it's going to be filled/changed as you reinit more elements later.
In the code you posted you are making a copy...

-- 
John

Re: [Libmesh-users] FEBase object fails to calculate values

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

On Wed, Jun 12, 2019 at 4:38 PM Nathan Andrew Miller <
Nat...@co...> wrote:

> I'm trying to compute the xyz, JxW, and other values at arbitrary points
> for a FEBase object during the evaluation of a MOOSE UserObject. I
> implemented the following in code:
>
> ```
> //Create a vector of points
> std::vector< Point > cell_points;
>
> ...things to fill cell_points...
>
> //Create a vector of ones (the weights)
> ones = std::vector< double > (cell_points.size(), 1);
>
> std::unique_ptr< libMesh::FEBase > fe(
> libMesh::FEBase::build(_mesh.dimension(),
> libMesh::FEType(_current_elem->default_order())));
>
> fe->reinit(_current_elem, &cell_points, &ones);
>
>
You have to pre-request that the xyz values be computed before you call
fe->reinit. So put the following line:


> std::vector< Point > xyz = fe->get_xyz();
>

before the reinit() call and it should work.

--
John

[Libmesh-users] FEBase object fails to calculate values

[Nathan A. M. <Nat...@co...>]

I'm trying to compute the xyz, JxW, and other values at arbitrary points
for a FEBase object during the evaluation of a MOOSE UserObject. I
implemented the following in code:

```
//Create a vector of points
std::vector< Point > cell_points;

...things to fill cell_points...

//Create a vector of ones (the weights)
ones = std::vector< double > (cell_points.size(), 1);

std::unique_ptr< libMesh::FEBase > fe(
libMesh::FEBase::build(_mesh.dimension(),
libMesh::FEType(_current_elem->default_order())));

fe->reinit(_current_elem, &cell_points, &ones);

std::vector< Point > xyz = fe->get_xyz();
```

following basically what I found in the third example. When I run this code
I hit the assertion:
"Assertion `!calculations_started || calculate_xyz' failed."

I have also tried substituting FEBase for FEGenericBase<Real> to identical
results.

Is there something that I'm missing in my code?

[Libmesh-users] TransientSystem::old_solution vs TransientSystem::old_local_solution

[Yuxiang W. <yw...@vi...>]

Dear all,

Quick question - in using the TransientSystem::old_solution vs
TransientSystem::old_local_solution, I noticed that the former seems to be
exactly the latter plus two size checks. Therefore, can I simply use the
latter (old_local_solution) if I am sure that the DOF number is correct?

Best,
Shawn

-- 
Yuxiang "Shawn" Wang, PhD
yw...@vi...
+1 (434) 284-0836

Re: [Libmesh-users] Mass lumping and trapezoidal quadrature rule

[marco <in...@gm...>]

Hallo John,

many thanks for your answer.

Yes, I agree, The condition I wrote is true only for low order elements.
For serendipity, and maybe also second order, elements it is not true.
For second order, some basis functions have zero integral.

Actually the difference that I have founds more related to "where" you
apply a quadrature that results in a lumped mass matrix.

You can write the integral over a generic element and use a "generic
lumping",
(i.e. a quadrature rule that gives a diagonal mass matrix on this
configuration)
or map to a reference element and use a "reference lumping" there.
If the map between the two configurations is not linear, as in the case of
a generic hexahedral/quadrialteral elements,
the two approaches result in different quadrature rules.

What I have also observed, but not proven and maybe it was only by chance,
is that the "algebraic lumping"
(i.e. summing the entradiagonal element to the diagonal one) coincides with
the approach "generic lumping"
if the the tridiagonal term does not appear in the map between the two
configurations.

If this term is present, the three approaches may give three "different"
lumping methods.

Best regards
Marco


On Tue, Jun 4, 2019 at 4:24 PM John Peterson <jwp...@gm...> wrote:

>
>
> On Wed, May 22, 2019 at 10:03 AM John Peterson <jwp...@gm...>
> wrote:
>
>>
>>
>> On Wed, May 22, 2019 at 3:30 AM marco <in...@gm...> wrote:
>>
>>> Mass lumping is defined by using trapezoidal quadrature rule.
>>> In this way, the weights of a trapezoidal rule should be the integral
>>> over
>>> the element of each basis function.
>>>
>>
> I looked into this a bit more carefully over the weekend, and while it may
> be technically true, I don't think it necessarily results in a "good"
> quadrature rule for every element, at least not for the "serendipity
> elements" (Quad8, Hex20).
>
> If you compute the element integral of one of the vertex basis functions
> of the Hex20, you get -1. The edge basis functions integrate to 4/3.
> Interestingly, such a rule is exact for quadratics, but using negative
> weights in a nodal quadrature rule seems very problematic to me. For
> example, it would give you negative diagonal entries for the mass matrix
> rows associated with the vertex basis functions...
>
>
> I noticed that this is not always true for hexahedral elements. Am I
>>> missing something or could there be a bug?
>>>
>>
> That being said, I think I have convinced myself that using the tensor
> product of 1D QSimspson rules on a Hex20 or Quad8 a) does not result in a
> nodal quadrature for such an element, and b) produces a non-diagonal mass
> matrix. It's definitely possible to "fix" this issue, but it's not clear to
> me what the best choice of weights should be. One choice, which is exact
> for quadratics, is the one with negative vertex weights mentioned above.
> Another choice of weights would be (vertex=1/7, edge=4/7), but this is
> chosen somewhat arbitrarily to match the 4:1 ratio of edge:vertex weights
> in Simpson's rule, and is only exact for linears. It may be possible to
> optimize the choice so that e.g. the mass matrix diagonals resulting from
> this quadrature are as close as possible to the "true" mass matrix
> diagonals (or their lumped equivalents)
>
> --
> John
>

Re: [Libmesh-users] Mass lumping and trapezoidal quadrature rule

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

On Wed, May 22, 2019 at 10:03 AM John Peterson <jwp...@gm...> wrote:

>
>
> On Wed, May 22, 2019 at 3:30 AM marco <in...@gm...> wrote:
>
>> Mass lumping is defined by using trapezoidal quadrature rule.
>> In this way, the weights of a trapezoidal rule should be the integral over
>> the element of each basis function.
>>
>
I looked into this a bit more carefully over the weekend, and while it may
be technically true, I don't think it necessarily results in a "good"
quadrature rule for every element, at least not for the "serendipity
elements" (Quad8, Hex20).

If you compute the element integral of one of the vertex basis functions of
the Hex20, you get -1. The edge basis functions integrate to 4/3.
Interestingly, such a rule is exact for quadratics, but using negative
weights in a nodal quadrature rule seems very problematic to me. For
example, it would give you negative diagonal entries for the mass matrix
rows associated with the vertex basis functions...


I noticed that this is not always true for hexahedral elements. Am I
>> missing something or could there be a bug?
>>
>
That being said, I think I have convinced myself that using the tensor
product of 1D QSimspson rules on a Hex20 or Quad8 a) does not result in a
nodal quadrature for such an element, and b) produces a non-diagonal mass
matrix. It's definitely possible to "fix" this issue, but it's not clear to
me what the best choice of weights should be. One choice, which is exact
for quadratics, is the one with negative vertex weights mentioned above.
Another choice of weights would be (vertex=1/7, edge=4/7), but this is
chosen somewhat arbitrarily to match the 4:1 ratio of edge:vertex weights
in Simpson's rule, and is only exact for linears. It may be possible to
optimize the choice so that e.g. the mass matrix diagonals resulting from
this quadrature are as close as possible to the "true" mass matrix
diagonals (or their lumped equivalents)

-- 
John

Re: [Libmesh-users] Projection helgrind error

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

Man this was harder to track down than it should have been.

Would you try adding the line:

SubFunctor::join(other);

to the end of SortAndCopy::join, around generic_projector.h:1649?

That seems to fix the problems I'm able to trigger easily; hoping it
will fix yours too.  I have to run and be AFK for a few hours but I'll
put it into a PR tonight; it's a huge bugfix even if it turns out not
to be the *only* bugfix we need.
---
Roy

On Thu, 16 May 2019, Alexander Lindsay wrote:

> Awesome, thanks Roy.
> 
> On Tue, May 14, 2019 at 2:36 PM Stogner, Roy H <roy...@ic...> wrote:
>
>       On Mon, 13 May 2019, Alexander Lindsay wrote:
>
>       > I could maybe think of a libmesh-only case, but if you're willing to
>       > run MOOSE, you can run the
>       > moose/test/tests/geomsearch/nearest_node_locator/nearest_node_locator.i
>       > input file. It appears to reproduce the error every time (with
>       > --n-threads=2).
>
>       I'm definitely managing to trigger libmesh-only errors with threaded
>       projections too, and the assertion failure I'm getting is more helpful
>       than that helgrind error, so I'm working from that angle first; when I
>       get a patch ready I'll let you know and if it doesn't fix your case
>       too then I'll try reproducing with MOOSE next.
>
>       Thanks,
>       ---
>       Roy
> 
> 
> This message is from an external sender. Learn more about why this matters.
> 
>