libmesh-users — General information for libmesh users

[Libmesh-users] libMesh make fatal error-(unsupported/Eigen/IterativeSolvers: No such file or directory)

[Braden F. <bf...@um...>]

Hello,

I'm a new linux user and I'm having difficulties getting libMesh properly
built on my system. The fatal error is occurring when I try to make
libMesh, specifically the problem is that its looking for  a file that
doesn't exist "unsupported/Eigen/IterativeSolvers: No such file or
directory". I followed the install documentation online to get libMesh
configured. The following excerpt below is from the report after libMesh
finished configuration. Notice the highlighted portion in green shows that
eigen is enabled:

Optional Packages:
  boost............................ : yes
  capnproto........................ : no
  cppunit.......................... : no
  curl............................. : no
  eigen............................ : yes
  exodus........................... : yes
     version....................... : v5.22
  fparser.......................... : yes
     build from version............ : release
  glpk............................. : no
  gmv.............................. : yes
  gzstream......................... : yes
  hdf5............................. : yes
  laspack.......................... : no
  libhilbert....................... : yes
  metis............................ : yes
  mpi.............................. : yes
  nanoflann........................ : yes
  nemesis.......................... : yes
     version....................... : v5.22
  netcdf........................... : yes
     version....................... : 4
  nlopt............................ : no
  parmetis......................... : yes
  petsc............................ : yes
     version....................... : 3.6.4
  qhull............................ : yes
  sfcurves......................... : no
  slepc............................ : yes
     version....................... : 3.6.1
  thread model..................... : pthread
  c++ rtti ........................ : yes
  tecio............................ : no
  tecplot...(vendor binaries)...... : no
  tetgen........................... : no
  triangle......................... : no
  trilinos......................... : no
  vtk.............................. : no

However, after running the make command, the following error message
results:

"src/solvers/eigen_sparse_linear_solver.C:34:46: fatal error:
unsupported/Eigen/IterativeSolvers: No such file or directory
compilation terminated.
Makefile:15986: recipe for target
'src/solvers/libmesh_dbg_la-eigen_sparse_linear_solver.lo'
failed
make[1]: *** [src/solvers/libmesh_dbg_la-eigen_sparse_linear_solver.lo]
Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/home/braden/Codes/libmesh'
Makefile:29154: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1"

I read in the eigen_sparse_linear_solver.C file that it calls the file
"IterativeSolvers" in the directory "unsupported/Eigen/". When I go to
libMesh_dir/contrib/eigen/3.2.9/unsupported/Eigen I see the file
"IterativeSolvers" and I can open it and see the following in a commented
section at the top:

/**
  * \defgroup IterativeSolvers_Module Iterative solvers module
  * This module aims to provide various iterative linear and non linear
solver algorithms.
  * It currently provides:
  *  - a constrained conjugate gradient
  *  - a Householder GMRES implementation
  * \code
  * #include <unsupported/Eigen/IterativeSolvers>
  * \endcode
  */

Several include statements follow with different header files for various
iterative solvers like Jacobi, GMRES, etc.

If this file exists then why is it saying that there is no such file or
directory? Any ideas on what the problem may be?

Thanks,
Braden Frigoletto

Re: [Libmesh-users] Defining two mesh objects (mesh_pos+ mesh_negative)

[Xiao Ma <xi...@il...>]

Hi Roy,


Thank you for your reply.
I think I will go with two separate equation systems one on each mesh.
The problem I am trying to solve is a two half plane and in between it is
governing by a friction model, and the friction contact is enforce by a
method "TSN" (Traction Separation nodes).
Say I have two half plane (mesh_pos,mesh_neg),  so the mesh_pos 's bottom
layer is gonna to be applied some traction , and the mesh_neg' top layer is
gonna be applied some traction to enforce the jump condition and also the
friction law.

So what I need is to have these two separate EquationsSystems(System for
mesh_pos, System for mesh_neg), two parts are solved separately but at the
same time step, the only interaction is through the traction at the
separate nodes.


Best,
Xiao

On Mon, Oct 30, 2017 at 9:53 AM, Roy Stogner <roy...@ic...>
wrote:

>
> On Sun, 29 Oct 2017, Xiao Ma wrote:
>
> > I am wondering if there is a way to define two mesh objects , which each
> > represents half of the domain, and solve the two part at the same time ,
> > mesh_pos and mesh_neg , two meshes are separated, they are not connected
> .
>
> Depends what you mean by "at the same time".  If you want to solve a
> fully coupled problem, then you can use
> ReplicatedMesh::stitch_meshes() to combine them into a single mesh,
> and solve the problem on that.  If you want to solve a weakly coupled
> problem, then you can create a System on each mesh... either as part
> of the same EquationSystems but using subdomain-specific variables, or
> as part of two separate EquationSystems, one on each mesh.
> ---
> Roy
>



-- 
-------------------------------------------------------------------------------------
*Xiao Ma*
Graduate Research Assistant
PhD student in Structural Engineering
University of Illinois at Urbana-Champaign
E-mail: *xi...@il... <xi...@il...>*
--------------------------------------------------------------------------------------

Re: [Libmesh-users] Defining two mesh objects (mesh_pos+ mesh_negative)

[Roy S. <roy...@ic...>]

On Sun, 29 Oct 2017, Xiao Ma wrote:

> I am wondering if there is a way to define two mesh objects , which each
> represents half of the domain, and solve the two part at the same time ,
> mesh_pos and mesh_neg , two meshes are separated, they are not connected .

Depends what you mean by "at the same time".  If you want to solve a
fully coupled problem, then you can use
ReplicatedMesh::stitch_meshes() to combine them into a single mesh,
and solve the problem on that.  If you want to solve a weakly coupled
problem, then you can create a System on each mesh... either as part
of the same EquationSystems but using subdomain-specific variables, or
as part of two separate EquationSystems, one on each mesh.
---
Roy

[Libmesh-users] Defining two mesh objects (mesh_pos+ mesh_negative)

[Xiao Ma <xi...@il...>]

Hi all,


I am wondering if there is a way to define two mesh objects , which each
represents half of the domain, and solve the two part at the same time ,
mesh_pos and mesh_neg , two meshes are separated, they are not connected .


Thank you,
Xiao
-- 
-------------------------------------------------------------------------------------
*Xiao Ma*
Graduate Research Assistant
PhD student in Structural Engineering
University of Illinois at Urbana-Champaign
E-mail: *xi...@il... <xi...@il...>*
--------------------------------------------------------------------------------------

Re: [Libmesh-users] library compilation problem

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

On Tue, Oct 24, 2017 at 10:38 PM, Michael Povolotskyi <mpo...@pu...>
wrote:

> Dear Libmesh developers,
>
> I have a problem during libmesh installation.
>
> ./contrib/eigen/eigen/Eigen/src/Core/util/Memory.h: In function ‘void*
> Eigen::internal::generic_aligned_realloc(void*, size_t, size_t)’:
> ./contrib/eigen/eigen/Eigen/src/Core/util/Memory.h:167: error:
> ‘__errno_location’ was not declared in this scope
>
> I attach config.log here.
>

Unfortunately attachments are not allowed on the libmesh-users list, so
nothing came through.

In addition to Roy's suggestion, if you could also let us know what
OS/compiler you are using, that would be helpful.

-- 
John

Re: [Libmesh-users] library compilation problem

[Roy S. <roy...@ic...>]

On Wed, 25 Oct 2017, Michael Povolotskyi wrote:

> I have a problem during libmesh installation.
>
> ./contrib/eigen/eigen/Eigen/src/Core/util/Memory.h: In function ‘void* 
> Eigen::internal::generic_aligned_realloc(void*, size_t, size_t)’:
> ./contrib/eigen/eigen/Eigen/src/Core/util/Memory.h:167: error: 
> ‘__errno_location’ was not declared in this scope

See

https://github.com/libMesh/libmesh/issues/1411

for some discussion.  We're still not sure how or even if it can be
generally fixed, but "use a newer compiler" is a possible workaround.
I'd be very interested to hear (preferably as another comment on that
issue, to keep it all together) whether or not a compiler upgrade
works for you too.
---
Roy

[Libmesh-users] library compilation problem

[Michael P. <mpo...@pu...>]

Dear Libmesh developers,

I have a problem during libmesh installation.


./contrib/eigen/eigen/Eigen/src/Core/util/Memory.h: In function ‘void* 
Eigen::internal::generic_aligned_realloc(void*, size_t, size_t)’:
./contrib/eigen/eigen/Eigen/src/Core/util/Memory.h:167: error: 
‘__errno_location’ was not declared in this scope

I attach config.log here.

Michael.

Re: [Libmesh-users] App spends lots of time in _eq.reinit()

[Roy S. <roy...@ic...>]

On Thu, 19 Oct 2017, Jesse Carter wrote:

> On Thu, Oct 19, 2017 at 10:38 AM, Roy Stogner <roy...@ic...> wrote:
>
>       I'll look through it soon, at least to see if there's any low-hanging
>       fruit.

One bit of embarrassing low-hanging fruit that I often forget: when
*really* benchmarking, remember that our libMesh::PerfLog has a bit of
a heisenbug: it does string manipulation to an extent that invalidates
its own results if we try to use it too fine-grained.

For example:

$ time ../../PRARIEDOG-opt -i 2d_sink_map_with_refinement.i UserObjects/terminator/expression="num_past_events>=20" Mesh/nx=20 Mesh/ny=20 Mesh/nz=20 Outputs/exodus=false --disable-perflog | tail -3
real    1m1.863s
user    1m0.642s
sys     0m0.136s

$ time ../../PRARIEDOG-opt -i 2d_sink_map_with_refinement.i UserObjects/terminator/expression="num_past_events>=20" Mesh/nx=20 Mesh/ny=20 Mesh/nz=20 Outputs/exodus=false | tail -3
real    1m51.894s
user    1m50.719s
sys     0m0.115s

That's actually pretty damning... it does take us less than a
microsecond to do each logging event, but since our logging is so fine
grained that it can run a hundred million times on a small problem,
that's not insignificant!  I had no idea it was so bad!  And I even
made it about 30% *worse* while I was working on the projection
refactoring, because I added more fine-grained logging there and
didn't remove it afterwards.

I know this is kind of a red herring, since "--disable-perflog" works
just fine, but I think I'm going to quickly see if I can get the
string allocation/deallocation out of our PerfLog operations, and if
doing so makes them cheap enough to leave enabled by default.
Otherwise we still need to do *something*, whether turning off the
finer grained logging, or even turning off logging by default in opt
mode, because "hope our performance-concerned users know to specify
--ironically-ignore-performance on the command line" is not a good
attitude...
---
Roy

Re: [Libmesh-users] How to use ExodusII_IO::copy_elemental_solution in parallel?

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

On Fri, Oct 20, 2017 at 10:17 AM, David Knezevic <dav...@ak...
> wrote:

> On Fri, Oct 20, 2017 at 12:08 PM, John Peterson <jwp...@gm...>
> wrote:
>
>>
>>
>> On Fri, Oct 20, 2017 at 9:53 AM, David Knezevic <
>> dav...@ak...> wrote:
>>
>>> On Fri, Oct 20, 2017 at 11:38 AM, John Peterson <jwp...@gm...>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Oct 20, 2017 at 9:19 AM, David Knezevic <
>>>> dav...@ak...> wrote:
>>>>
>>>>> I'm using ExodusII_IO::copy_elemental_solution to copy element data
>>>>> to a new System object, and this works fine in serial using code like the
>>>>> below:
>>>>>
>>>>> ----------------------------------------------
>>>>>
>>>>>   Mesh mesh(comm);
>>>>>   ExodusII_IO exo_io(mesh);
>>>>>
>>>>>   if (comm.rank() == 0)
>>>>>   {
>>>>>     exo_io.read(path_to_mesh_file);
>>>>>   }
>>>>>   MeshCommunication().broadcast(mesh);
>>>>>
>>>>>   mesh.prepare_for_use();
>>>>>
>>>>>   EquationSystems es(mesh);
>>>>>   ExplicitSystem& materials_system =
>>>>>     es->add_system<ExplicitSystem> ("data");
>>>>>   materials_system.add_variable ("data", CONSTANT, MONOMIAL);
>>>>>   es->init();
>>>>>
>>>>>   exo_io.copy_elemental_solution(es, "data", "data");
>>>>>
>>>>> ----------------------------------------------
>>>>>
>>>>>
>>>>> However, in parallel I hit the error "ERROR, ExodusII file must be
>>>>> opened for reading before copying an elemental solution!" at the start of
>>>>> copy_elemental_solution.
>>>>>
>>>>> As far as I know (e.g. based on namebased_io.C) we should only call
>>>>> "read" on proc 0, so I don't see how to make this work in parallel, since
>>>>> in that case exo_io is only "opened for reading" on proc 0.
>>>>>
>>>>> Does anyone have any suggestions on this? (John, I gather that you
>>>>> were the author of most of the ExodusII reader stuff, so I thought you
>>>>> might know the answer?)
>>>>>
>>>>
>>>> Hmm... I think copy_elemental_solution() is only designed to work in
>>>> serial, so could we just guard the parts the parts of that function that
>>>> read from the file in "if (rank==0)"?
>>>>
>>>> In addition, we would only error out if the file is not open for
>>>> reading on proc 0...
>>>>
>>>
>>> OK, that makes sense. I think we could just wrap the whole method (up to
>>> solution->close) in "if (rank==0)", and remove the "if" around
>>> system.solution->set so that all values are set on proc 0 and then
>>> communicated when we close the vector. Do you agree?
>>>
>>
>> Yeah, that inner if-test around solution->set doesn't need to be there,
>> and solution->close() is the first collective I see.
>>
>
>
> OK, I'll test that, and make a PR.
>
> Question: Will the "dof_index = elem->dof_number..." line work when elem
> is not owned by proc 0?
>

I think that's right, yes. We just do some indexing magic that doesn't
require parallel communication in DofObject::dof_number().

-- 
John

Re: [Libmesh-users] How to use ExodusII_IO::copy_elemental_solution in parallel?

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

On Fri, Oct 20, 2017 at 12:08 PM, John Peterson <jwp...@gm...>
wrote:

>
>
> On Fri, Oct 20, 2017 at 9:53 AM, David Knezevic <
> dav...@ak...> wrote:
>
>> On Fri, Oct 20, 2017 at 11:38 AM, John Peterson <jwp...@gm...>
>> wrote:
>>
>>>
>>>
>>> On Fri, Oct 20, 2017 at 9:19 AM, David Knezevic <
>>> dav...@ak...> wrote:
>>>
>>>> I'm using ExodusII_IO::copy_elemental_solution to copy element data to
>>>> a new System object, and this works fine in serial using code like the
>>>> below:
>>>>
>>>> ----------------------------------------------
>>>>
>>>>   Mesh mesh(comm);
>>>>   ExodusII_IO exo_io(mesh);
>>>>
>>>>   if (comm.rank() == 0)
>>>>   {
>>>>     exo_io.read(path_to_mesh_file);
>>>>   }
>>>>   MeshCommunication().broadcast(mesh);
>>>>
>>>>   mesh.prepare_for_use();
>>>>
>>>>   EquationSystems es(mesh);
>>>>   ExplicitSystem& materials_system =
>>>>     es->add_system<ExplicitSystem> ("data");
>>>>   materials_system.add_variable ("data", CONSTANT, MONOMIAL);
>>>>   es->init();
>>>>
>>>>   exo_io.copy_elemental_solution(es, "data", "data");
>>>>
>>>> ----------------------------------------------
>>>>
>>>>
>>>> However, in parallel I hit the error "ERROR, ExodusII file must be
>>>> opened for reading before copying an elemental solution!" at the start of
>>>> copy_elemental_solution.
>>>>
>>>> As far as I know (e.g. based on namebased_io.C) we should only call
>>>> "read" on proc 0, so I don't see how to make this work in parallel, since
>>>> in that case exo_io is only "opened for reading" on proc 0.
>>>>
>>>> Does anyone have any suggestions on this? (John, I gather that you were
>>>> the author of most of the ExodusII reader stuff, so I thought you might
>>>> know the answer?)
>>>>
>>>
>>> Hmm... I think copy_elemental_solution() is only designed to work in
>>> serial, so could we just guard the parts the parts of that function that
>>> read from the file in "if (rank==0)"?
>>>
>>> In addition, we would only error out if the file is not open for reading
>>> on proc 0...
>>>
>>
>> OK, that makes sense. I think we could just wrap the whole method (up to
>> solution->close) in "if (rank==0)", and remove the "if" around
>> system.solution->set so that all values are set on proc 0 and then
>> communicated when we close the vector. Do you agree?
>>
>
> Yeah, that inner if-test around solution->set doesn't need to be there,
> and solution->close() is the first collective I see.
>


OK, I'll test that, and make a PR.

Question: Will the "dof_index = elem->dof_number..." line work when elem is
not owned by proc 0?

David

Re: [Libmesh-users] How to use ExodusII_IO::copy_elemental_solution in parallel?

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

On Fri, Oct 20, 2017 at 9:53 AM, David Knezevic <dav...@ak...>
wrote:

> On Fri, Oct 20, 2017 at 11:38 AM, John Peterson <jwp...@gm...>
> wrote:
>
>>
>>
>> On Fri, Oct 20, 2017 at 9:19 AM, David Knezevic <
>> dav...@ak...> wrote:
>>
>>> I'm using ExodusII_IO::copy_elemental_solution to copy element data to
>>> a new System object, and this works fine in serial using code like the
>>> below:
>>>
>>> ----------------------------------------------
>>>
>>>   Mesh mesh(comm);
>>>   ExodusII_IO exo_io(mesh);
>>>
>>>   if (comm.rank() == 0)
>>>   {
>>>     exo_io.read(path_to_mesh_file);
>>>   }
>>>   MeshCommunication().broadcast(mesh);
>>>
>>>   mesh.prepare_for_use();
>>>
>>>   EquationSystems es(mesh);
>>>   ExplicitSystem& materials_system =
>>>     es->add_system<ExplicitSystem> ("data");
>>>   materials_system.add_variable ("data", CONSTANT, MONOMIAL);
>>>   es->init();
>>>
>>>   exo_io.copy_elemental_solution(es, "data", "data");
>>>
>>> ----------------------------------------------
>>>
>>>
>>> However, in parallel I hit the error "ERROR, ExodusII file must be
>>> opened for reading before copying an elemental solution!" at the start of
>>> copy_elemental_solution.
>>>
>>> As far as I know (e.g. based on namebased_io.C) we should only call
>>> "read" on proc 0, so I don't see how to make this work in parallel, since
>>> in that case exo_io is only "opened for reading" on proc 0.
>>>
>>> Does anyone have any suggestions on this? (John, I gather that you were
>>> the author of most of the ExodusII reader stuff, so I thought you might
>>> know the answer?)
>>>
>>
>> Hmm... I think copy_elemental_solution() is only designed to work in
>> serial, so could we just guard the parts the parts of that function that
>> read from the file in "if (rank==0)"?
>>
>> In addition, we would only error out if the file is not open for reading
>> on proc 0...
>>
>
> OK, that makes sense. I think we could just wrap the whole method (up to
> solution->close) in "if (rank==0)", and remove the "if" around
> system.solution->set so that all values are set on proc 0 and then
> communicated when we close the vector. Do you agree?
>

Yeah, that inner if-test around solution->set doesn't need to be there, and
solution->close() is the first collective I see.

-- 
John

Re: [Libmesh-users] How to use ExodusII_IO::copy_elemental_solution in parallel?

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

On Fri, Oct 20, 2017 at 11:38 AM, John Peterson <jwp...@gm...>
wrote:

>
>
> On Fri, Oct 20, 2017 at 9:19 AM, David Knezevic <
> dav...@ak...> wrote:
>
>> I'm using ExodusII_IO::copy_elemental_solution to copy element data to a
>> new System object, and this works fine in serial using code like the below:
>>
>> ----------------------------------------------
>>
>>   Mesh mesh(comm);
>>   ExodusII_IO exo_io(mesh);
>>
>>   if (comm.rank() == 0)
>>   {
>>     exo_io.read(path_to_mesh_file);
>>   }
>>   MeshCommunication().broadcast(mesh);
>>
>>   mesh.prepare_for_use();
>>
>>   EquationSystems es(mesh);
>>   ExplicitSystem& materials_system =
>>     es->add_system<ExplicitSystem> ("data");
>>   materials_system.add_variable ("data", CONSTANT, MONOMIAL);
>>   es->init();
>>
>>   exo_io.copy_elemental_solution(es, "data", "data");
>>
>> ----------------------------------------------
>>
>>
>> However, in parallel I hit the error "ERROR, ExodusII file must be opened
>> for reading before copying an elemental solution!" at the start of
>> copy_elemental_solution.
>>
>> As far as I know (e.g. based on namebased_io.C) we should only call
>> "read" on proc 0, so I don't see how to make this work in parallel, since
>> in that case exo_io is only "opened for reading" on proc 0.
>>
>> Does anyone have any suggestions on this? (John, I gather that you were
>> the author of most of the ExodusII reader stuff, so I thought you might
>> know the answer?)
>>
>
> Hmm... I think copy_elemental_solution() is only designed to work in
> serial, so could we just guard the parts the parts of that function that
> read from the file in "if (rank==0)"?
>
> In addition, we would only error out if the file is not open for reading
> on proc 0...
>

OK, that makes sense. I think we could just wrap the whole method (up to
solution->close) in "if (rank==0)", and remove the "if" around
system.solution->set so that all values are set on proc 0 and then
communicated when we close the vector. Do you agree?

David

Re: [Libmesh-users] How to use ExodusII_IO::copy_elemental_solution in parallel?

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

On Fri, Oct 20, 2017 at 9:19 AM, David Knezevic <dav...@ak...>
wrote:

> I'm using ExodusII_IO::copy_elemental_solution to copy element data to a
> new System object, and this works fine in serial using code like the below:
>
> ----------------------------------------------
>
>   Mesh mesh(comm);
>   ExodusII_IO exo_io(mesh);
>
>   if (comm.rank() == 0)
>   {
>     exo_io.read(path_to_mesh_file);
>   }
>   MeshCommunication().broadcast(mesh);
>
>   mesh.prepare_for_use();
>
>   EquationSystems es(mesh);
>   ExplicitSystem& materials_system =
>     es->add_system<ExplicitSystem> ("data");
>   materials_system.add_variable ("data", CONSTANT, MONOMIAL);
>   es->init();
>
>   exo_io.copy_elemental_solution(es, "data", "data");
>
> ----------------------------------------------
>
>
> However, in parallel I hit the error "ERROR, ExodusII file must be opened
> for reading before copying an elemental solution!" at the start of
> copy_elemental_solution.
>
> As far as I know (e.g. based on namebased_io.C) we should only call "read"
> on proc 0, so I don't see how to make this work in parallel, since in that
> case exo_io is only "opened for reading" on proc 0.
>
> Does anyone have any suggestions on this? (John, I gather that you were
> the author of most of the ExodusII reader stuff, so I thought you might
> know the answer?)
>

Hmm... I think copy_elemental_solution() is only designed to work in
serial, so could we just guard the parts the parts of that function that
read from the file in "if (rank==0)"?

In addition, we would only error out if the file is not open for reading on
proc 0...

-- 
John

[Libmesh-users] How to use ExodusII_IO::copy_elemental_solution in parallel?

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

I'm using ExodusII_IO::copy_elemental_solution to copy element data to a
new System object, and this works fine in serial using code like the below:

----------------------------------------------

  Mesh mesh(comm);
  ExodusII_IO exo_io(mesh);

  if (comm.rank() == 0)
  {
    exo_io.read(path_to_mesh_file);
  }
  MeshCommunication().broadcast(mesh);

  mesh.prepare_for_use();

  EquationSystems es(mesh);
  ExplicitSystem& materials_system =
    es->add_system<ExplicitSystem> ("data");
  materials_system.add_variable ("data", CONSTANT, MONOMIAL);
  es->init();

  exo_io.copy_elemental_solution(es, "data", "data");

----------------------------------------------


However, in parallel I hit the error "ERROR, ExodusII file must be opened
for reading before copying an elemental solution!" at the start of
copy_elemental_solution.

As far as I know (e.g. based on namebased_io.C) we should only call "read"
on proc 0, so I don't see how to make this work in parallel, since in that
case exo_io is only "opened for reading" on proc 0.

Does anyone have any suggestions on this? (John, I gather that you were the
author of most of the ExodusII reader stuff, so I thought you might know
the answer?)

Thanks!
David

Re: [Libmesh-users] Explicit Central difference time integration

[Roy S. <roy...@ic...>]

On Sat, 14 Oct 2017, Xiao Ma wrote:

> I am trying to solve a transient problem using explicit integration scheme
> (e.g central difference in time) with a lumpped mass technique solving a
> wave propagation problem.
>
> I am wondering if there is anything that is close to this purpose ?

Not to my knowledge.

> Due to the explicit integration scheme , I don't need to form a stiffness
> matrix K , so do I still need to use the Equationsystem class ?

Yes; you'll just need to make sure to only add ExplicitSystem-derived,
not ImplicitSystem-derived, systems to it.

> If I want to still use the Equationsystem class , is there a
> ExplcitTransient System available ?

Close: TransientExplicitSystem, in transient_system.h

> Bascily what I am gonna do is just :
>
> acceleration = F_ext./M_lumpped
> velocity = v_n+dt*accleration
> disp = u_n + dt*velocity
>
> The solve is just cwiseQuotient (coefficient wise Quotient product) of two
> vectors .

That all sounds reasonable.

You might run into performance issues, though.  Most libMesh users do
implicit solves exclusively, so we've never really heavily optimized
the library as used by an explicit application.  If performance turns
out to be a problem for you then let us know and we might be able to
help improve it.
---
Roy

Re: [Libmesh-users] ContinuationSystem example

[Vasileios V. <va...@gm...>]

Thanks John for the message. I am aware of your contribution in that end, however, I was wondering if there was any progress with that class to any other physics problem.

However, I would appreciate sharing your code, which (after reviewing to understand more about the class and its implementation) I would like to use in both developing the code for my problem and, also, preparing a simple example code in elastostatics (a network of trusses maybe?).

cheers,
Vasileios





> On 13 Oct 2017, at 19:08, John Peterson <jwp...@gm...> wrote:
> 
> 
> 
> On Fri, Oct 13, 2017 at 12:57 AM, Vasileios Vavourakis <va...@gm... <mailto:va...@gm...>> wrote:
> Dear all,
> 
> I was wondering if anyone has available to share with the users-list an
> example that utilises the *libMesh::ContinuationSystem* class.
> 
> I aim developing a code in 3D elastostatics of a fibre-reinforced inelastic
> material (that undergoes large deformations).
> As such, it occurs to me that the arc-length method is a viable solution,
> since it may overcome some of the limitations inherent to the conventional
> Newton-Raphson method.
> 
> Look forward to hearing your thoughts and testing your example codes (:
> 
> This was a class I used in some work for my dissertation. I do still have some code laying around from that which I can send you, but it has not been maintained over the years... I should really add a libmesh example that demonstrates its use as well, but I'm not sure when I would have time to do it.
> 
> -- 
> John

[Libmesh-users] Explicit Central difference time integration

[Xiao Ma <xi...@il...>]

Dear all,


I am trying to solve a transient problem using explicit integration scheme
(e.g central difference in time) with a lumpped mass technique solving a
wave propagation problem.

I am wondering if there is anything that is close to this purpose ?

Due to the explicit integration scheme , I don't need to form a stiffness
matrix K , so do I still need to use the Equationsystem class ?



If I want to still use the Equationsystem class , is there a
ExplcitTransient System available ?

Bascily what I am gonna do is just :

acceleration = F_ext./M_lumpped
velocity = v_n+dt*accleration
disp = u_n + dt*velocity


The solve is just cwiseQuotient (coefficient wise Quotient product) of two
vectors .



Thank you ,
Xiao





-- 
-------------------------------------------------------------------------------------
*Xiao Ma*
Graduate Research Assistant
PhD student in Structural Engineering
University of Illinois at Urbana-Champaign
E-mail: *xi...@il... <xi...@il...>*
--------------------------------------------------------------------------------------

Re: [Libmesh-users] ContinuationSystem example

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

On Fri, Oct 13, 2017 at 12:57 AM, Vasileios Vavourakis <va...@gm...>
wrote:

> Dear all,
>
> I was wondering if anyone has available to share with the users-list an
> example that utilises the *libMesh::ContinuationSystem* class.
>
> I aim developing a code in 3D elastostatics of a fibre-reinforced inelastic
> material (that undergoes large deformations).
> As such, it occurs to me that the arc-length method is a viable solution,
> since it may overcome some of the limitations inherent to the conventional
> Newton-Raphson method.
>
> Look forward to hearing your thoughts and testing your example codes (:
>

This was a class I used in some work for my dissertation. I do still have
some code laying around from that which I can send you, but it has not been
maintained over the years... I should really add a libmesh example that
demonstrates its use as well, but I'm not sure when I would have time to do
it.

-- 
John

[Libmesh-users] ContinuationSystem example

[Vasileios V. <va...@gm...>]

Dear all,

I was wondering if anyone has available to share with the users-list an
example that utilises the *libMesh::ContinuationSystem* class.

I aim developing a code in 3D elastostatics of a fibre-reinforced inelastic
material (that undergoes large deformations).
As such, it occurs to me that the arc-length method is a viable solution,
since it may overcome some of the limitations inherent to the conventional
Newton-Raphson method.

Look forward to hearing your thoughts and testing your example codes (:

Best regards,
Vasileios

Re: [Libmesh-users] Lagrange factors

[Tobias M. <tob...@un...>]

Hi David,
Thank you for your fast answer. Indeed, I was not aware that in systems_of_equations_ex5 Lagrange multipliers are used as well; but it is only one DOF there as well, isn't?
The problem in my case is that I don't know before, how many DOFs refer to the L (see matrix block sturcture) and how many to the actual problem described by H.
But maybe I need to write a function that separates the parts on my own.
Best,
Tobias

________________________________
Von: David Knezevic [dav...@ak...]
Gesendet: Mittwoch, 11. Oktober 2017 13:03
An: Tobias Möhle
Cc: lib...@li...
Betreff: Re: [Libmesh-users] Lagrange factors

On Wed, Oct 11, 2017 at 5:02 AM, Tobias Möhle <tob...@un...<mailto:tob...@un...>> wrote:
Dear all,
I am trying to extend my current code to add Lagrange multipliers, leading to extra terms that couplet certain DOFs in a fixed range of the grid.
To do so, I added another variable to my system, leading to the system-matrix of block-structure:

/ H L^T \
\ L  0     /
where H is the matrix corresponding to the actual problem and L contains the Lagrange constrains.
Thus, my system.solution contains in the first part the coefficients of the particular solution and in the lower part the Lagrange multipliers themselves.
Now my question: is there some function to extract the Lagrange multipliers and the actual solution vector (dof-based) separately? Or how is it supposed to be done?


I suggest you refer to systems_of_equations_ex5, since that uses a Lagrange multiplier to impose a constraint. Hopefully that answers your question.

David

Re: [Libmesh-users] L2 Projection in example sys_of_eqn_ex6

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

We use a discontinuous basis, L2_LAGRANGE, so you can do an element-local
projection with no problem. The dofs are duplicated.

David


On Thu, Oct 12, 2017 at 12:35 PM, Renato Poli <re...@gm...> wrote:

> Hi,
>
> I believe this is a simple conceptual doubt on FEM and stress recovery -
> perhaps you can help me with some reference literature or brief clue...
>
> Concerning example system_of_equations_ex6.
>
> In funcion "compute_stress", it calculates a L2 projection of the stresses,
> element by element, right?
>
> My doubt is related to setting the degree of freedom values in:
> >> stress_system.solution->set(dof_index, projected_data(index));
>
> Won't multiple elements set  the same dof? Will it be set multiple times?
> Did I miss something?
>
> Thanks,
> Renato
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Libmesh-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>

[Libmesh-users] L2 Projection in example sys_of_eqn_ex6

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

Hi,

I believe this is a simple conceptual doubt on FEM and stress recovery -
perhaps you can help me with some reference literature or brief clue...

Concerning example system_of_equations_ex6.

In funcion "compute_stress", it calculates a L2 projection of the stresses,
element by element, right?

My doubt is related to setting the degree of freedom values in:
>> stress_system.solution->set(dof_index, projected_data(index));

Won't multiple elements set  the same dof? Will it be set multiple times?
Did I miss something?

Thanks,
Renato

Re: [Libmesh-users] getpot bug report

[simone <sob...@ya...>]

> Okay; I'll see what I can do.  This is an API backwards compatibility
> issue, so I'll need to be careful.  We'll definitely want a
> --with-getpot-namespace= option, and we'll be bending the rules if we
> don't default to the previous-API-compatible value for at least one
> release...
>
> Would "requires libMesh n.n+ configured with
> --with-getpot-namepace=libMesh, or libMesh n.m+" be good enough?
>
Sure! It would be perfect to me, I really thank you.
>
> Ah, I see.  That's definitely an issue.  I presume the GnuPlotIO class
> was *only* written to handle solution plotting, but unlike some of our
> other IO classes in that category, it doesn't *enforce* that
> limitation at compile time by requiring the EquationSystems to be
> provided to the constructor, nor does it even document that
> limitation...
>
> I don't have time to fix it or test the fix, but if you want to try
> then there might be an easy hack: in write_solution just use 0 instead
> of (*soln)[someindex] if soln is null, and use "Mesh" instead of
> (*names)[0] if names is null.
> ---

I'll try it, I'll follow your clue, I think i won't have any problem.
Thank you again

Simone

Re: [Libmesh-users] getpot bug report

[Roy S. <roy...@ic...>]

On Wed, 11 Oct 2017, simone wrote:

> I realize that my wording has been possibly misleading (I apologize for
> my English). What I meant by "forced" is not that I already have
> external users, but that my library once released will be delivered to
> users using the standard GetPot version, and using a default
> installation of libMesh; I will not be in a position to ask those users
> to recompile their libMesh; however, if I correctly understand your
> mail, your point 2 would be just great: I understand that you could
> release a new libMesh version in which the namespace is defaulted to
> "libmesh" or something like that. That would work just fine, because I
> am allowed to tell my users that my library "requires libMesh n.n.n or
> following".
>
> If point 2 could be worked out as I understood, then I could manually
> patch and recompile my libMesh installation according to your
> directives, as long as I have the number of the future libMesh release
> that will implement the behaviour we need.

Okay; I'll see what I can do.  This is an API backwards compatibility
issue, so I'll need to be careful.  We'll definitely want a
--with-getpot-namespace= option, and we'll be bending the rules if we
don't default to the previous-API-compatible value for at least one
release...

Would "requires libMesh n.n+ configured with
--with-getpot-namepace=libMesh, or libMesh n.m+" be good enough?

> I've noticed that the method used to print the mesh is a different
> one; i.e. in introduction_ex4.C I have
>
>       GnuPlotIO plot(mesh, "Introduction Example 4, 1D",
> GnuPlotIO::GRID_ON);
>       plot.write_equation_systems("gnuplot_script", equation_systems);
>
> which implies the creation of an EquationSystems object; at the moment
> it's out of my scope, since I just need to visualize the mesh and the
> simpler GnuPlotIO::write(std::string) method seemed perfectly fitting my
> needs;
> of course if necessary I can use the pattern used in the examples to do
> this work, but I found strange the behaviour of the write method, I
> thought it should be reported.

Ah, I see.  That's definitely an issue.  I presume the GnuPlotIO class
was *only* written to handle solution plotting, but unlike some of our
other IO classes in that category, it doesn't *enforce* that
limitation at compile time by requiring the EquationSystems to be
provided to the constructor, nor does it even document that
limitation...

I don't have time to fix it or test the fix, but if you want to try
then there might be an easy hack: in write_solution just use 0 instead
of (*soln)[someindex] if soln is null, and use "Mesh" instead of
(*names)[0] if names is null.
---
Roy

Re: [Libmesh-users] getpot bug report

[simone <sob...@ya...>]

I really thank you for your availability and for your help.

> I'm afraid our email list typically strips attachments.  I think I
> understand the problem from your description alone, but if I'm wrong
> then you could send to my email address specifically with the
> attachment.
>
Nevermind the attachment, you perfectly got the point: the crush is
indeed in the destructor, I think it's not necessary to send the package
to your private mail, thank you anyway.

> 1) Use one definition: use the libMesh GetPot.  I assume from "forced"
> that this isn't an option.
Unfortunately you're right, I can't do it
>
> 2) Use two different functions.  This is what libMesh was trying to
> enable via the GETPOT_NAMESPACE option.  In hindsight I now see that
> we obviously should have defaulted that to "libMesh" rather than
> undefined, in our own usage... but if you have external users then
> it's probably too late for you for us to do that now.  If I'm wrong
> about that let us know.
>
> Conversely, even if the original GetPot author hasn't added the same
> functionality, it wouldn't be hard for you to patch in manually... but
> I assume if you're "forced" to use his GetPot then you're probably not
> allowed to modify it either?
>

I realize that my wording has been possibly misleading (I apologize for
my English). What I meant by "forced" is not that I already have
external users, but that my library once released will be delivered to
users using the standard GetPot version, and using a default
installation of libMesh; I will not be in a position to ask those users
to recompile their libMesh; however, if I correctly understand your
mail, your point 2 would be just great: I understand that you could
release a new libMesh version in which the namespace is defaulted to
"libmesh" or something like that. That would work just fine, because I
am allowed to tell my users that my library "requires libMesh n.n.n or
following".

If point 2 could be worked out as I understood, then I could manually
patch and recompile my libMesh installation according to your
directives, as long as I have the number of the future libMesh release
that will implement the behaviour we need.


Point 3) and 4) I guess could be good solutions, but they both are out
of my range of action.

>
>> Another question, about public method: libMesh::GnuPlotIO::write(fname)
>>
>> It seems to do nothing but raising an exception,
>
> What exception?  From what line?  These are very important details.
I'm sorry, I've been lazy!
The exception is raised by line 81 of gnuplot_io.C file (I'm referring
to file taken from the website documentation, which coincides with my
local installation one):

      libmesh_assert ((names != libmesh_nullptr) && (soln !=
libmesh_nullptr));

which is part of the GnuPlotIO::write_solution method, called at line 45
of the same file by public method GnuPlot::write:

  this->write_solution(fname);

names and soln are parameters to be passed to write_solution method,
defaulted to libmesh_nullptr; since it seems to me they are not being
modified before the mentioned libmesh_assert call, I guess the only
possible result of calling GnuPlotIO::write(file_name) could be to have
an exception raised.
>
>> Is there a way to print a 1d mesh on a gnuplot readable file as the
>> method is depicted to do in the class documentation?
>
> I certainly believe so.  Four of our example codes do it, and I do see
> gnuplot_script and gnuplot_script_data output files for each of them
> in my build directory from "make check" yesterday.  Do those work for
> you or throw the same exception?

They all works fine also in my installation, but viewing at the source
code of those examples I've noticed that the method used to print the
mesh is a different one; i.e. in introduction_ex4.C I have

      GnuPlotIO plot(mesh, "Introduction Example 4, 1D",
GnuPlotIO::GRID_ON);
      plot.write_equation_systems("gnuplot_script", equation_systems);

which implies the creation of an EquationSystems object; at the moment
it's out of my scope, since I just need to visualize the mesh and the
simpler GnuPlotIO::write(std::string) method seemed perfectly fitting my
needs;
of course if necessary I can use the pattern used in the examples to do
this work, but I found strange the behaviour of the write method, I
thought it should be reported.

I hope I've been clear and I'm not losing anything which could simply
answer to my question.
I thank you again for your answer and help.

Best regards,
Simone