libmesh-users — General information for libmesh users

[Libmesh-users] Fwd: PDE Software Frameworks 2018 -- May 28-30, Hotel Zander K, Bergen, Norway.

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

Greetings all,

Please see the information below from Dr. Kloefkorn about PDESoft18 in
Bergen, Norway.

It would be great to have libmesh and MOOSE represented at this conference
in some way!

-- 
John


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

Dear friends and colleagues,

It is a great pleasure to announce the PDE Software Frameworks (PDESoft)
2018 Conference, which will be held at the hotel Zander K
(https://www.zanderk.no/en/), Bergen, Norway, May 28 - 30, 2018.

The scientific committee of the conference consists of the following people:

- Donna Calhoun (Boise State University)
- Guido Kanschat (Heidelberg University)
- Eirik Keilegavlen (University of Bergen)
- Robert Klöfkorn (International Research Institute of Stavanger)
- Lois Curfman McInnes (Argonne National Laboratory)
- Lawrence Mitchell (Imperial College London)
- Christophe Prud'homme (University of Strasbourg)
- Garth Wells (University of Cambridge)
- Barbara Wohlmuth (Technical University of Munich)

We welcome abstracts on topics related to software for
- meshing and adaptive mesh refinement,
- solvers for large systems of equations,
- numerical PDE solvers,
- data visualization systems,
- user interfaces to scientific software, and
- reproducible science.

The accepted abstracts will be scheduled for either oral or poster
presentations. This workshop does not publish full papers, so submission
of a full paper is not required. The deadline for abstract submission is
Feb. 1, 2018.

For more information, please see the PDESoft18 web page:
http://www.iris.no/pdesoft18/.

We are looking forward to meeting you in Bergen.

With best regards,

Robert Klöfkorn, on behalf of the organizing committee

--
Dr. Robert Kloefkorn

Senior Research Scientist | http://www.iris.no
International Research Institute of Stavanger (Bergen office)
Thormoehlensgt. 55 | 5006 Bergen
Phone: +47 482 93 024

[Libmesh-users] Newmark System: Boundary Condition on Velocity?

[Zack V. <jan...@gm...>]

Transient Systems Example 2 uses the Newmark System and applies Dirichlet
BCs on the displacement for the wave equation (called pressure in that
context)

How would I modify this example to impose conditions instead on the
velocity (if possible, without explicitly creating a new system for that
variable?)

Re: [Libmesh-users] problems during installation

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

This issue is fixed in 1.2.1 which has an upgraded netcdf.


> On Dec 19, 2017, at 4:07 PM, Michael Povolotskyi <mpo...@pu...> wrote:
> 
> Dear Libmesh support team,
> 
> I'm installing libmesh on a new PC with Fedora, and I have got the following error:
> 
> make[5]: Leaving directory '/home/mpovolot/Work/repo/libs/libmesh/openMPI/libmesh-1.2.0/contrib/netcdf/v4/liblib'
> make[4]: Leaving directory '/home/mpovolot/Work/repo/libs/libmesh/openMPI/libmesh-1.2.0/contrib/netcdf/v4/liblib'
> Making install in ncgen3
> make[4]: Entering directory '/home/mpovolot/Work/repo/libs/libmesh/openMPI/libmesh-1.2.0/contrib/netcdf/v4/ncgen3'
>   CCLD     ncgen3
> ../liblib/.libs/libnetcdf.so: undefined reference to `H5Pset_fapl_mpiposix'
> collect2: error: ld returned 1 exit status
> make[4]: *** [Makefile:491: ncgen3] Error 1
> make[4]: Leaving directory '/home/mpovolot/Work/repo/libs/libmesh/openMPI/libmesh-1.2.0/contrib/netcdf/v4/ncgen3'
> make[3]: *** [Makefile:610: install-recursive] Error 1
> make[3]: Leaving directory '/home/mpovolot/Work/repo/libs/libmesh/openMPI/libmesh-1.2.0/contrib/netcdf/v4'
> make[2]: *** [Makefile:978: install-recursive] Error 1
> make[2]: Leaving directory '/home/mpovolot/Work/repo/libs/libmesh/openMPI/libmesh-1.2.0/contrib'
> make[1]: *** [Makefile:29051: install-recursive] Error 1
> make[1]: Leaving directory '/home/mpovolot/Work/repo/libs/libmesh/openMPI/libmesh-1.2.0'
> make: *** [Makefile.openmpi:28: build] Error 2
> 87.934u 15.745s 0:55.97 185.2%  0+0k 51736+664688io 65pf+0w
> 
> I googled it, looks like it is a known issue, but I do not know how to proceed. Can I simply avoid netcdf build?
> 
> I attach my configuration log.
> 
> Thank you,
> 
> Michael.
> 
> 
> ------------------------------------------------------------------------------
> 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] problems during installation

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

Dear Libmesh support team,

I'm installing libmesh on a new PC with Fedora, and I have got the 
following error:

make[5]: Leaving directory 
'/home/mpovolot/Work/repo/libs/libmesh/openMPI/libmesh-1.2.0/contrib/netcdf/v4/liblib'
make[4]: Leaving directory 
'/home/mpovolot/Work/repo/libs/libmesh/openMPI/libmesh-1.2.0/contrib/netcdf/v4/liblib'
Making install in ncgen3
make[4]: Entering directory 
'/home/mpovolot/Work/repo/libs/libmesh/openMPI/libmesh-1.2.0/contrib/netcdf/v4/ncgen3'
   CCLD     ncgen3
../liblib/.libs/libnetcdf.so: undefined reference to `H5Pset_fapl_mpiposix'
collect2: error: ld returned 1 exit status
make[4]: *** [Makefile:491: ncgen3] Error 1
make[4]: Leaving directory 
'/home/mpovolot/Work/repo/libs/libmesh/openMPI/libmesh-1.2.0/contrib/netcdf/v4/ncgen3'
make[3]: *** [Makefile:610: install-recursive] Error 1
make[3]: Leaving directory 
'/home/mpovolot/Work/repo/libs/libmesh/openMPI/libmesh-1.2.0/contrib/netcdf/v4'
make[2]: *** [Makefile:978: install-recursive] Error 1
make[2]: Leaving directory 
'/home/mpovolot/Work/repo/libs/libmesh/openMPI/libmesh-1.2.0/contrib'
make[1]: *** [Makefile:29051: install-recursive] Error 1
make[1]: Leaving directory 
'/home/mpovolot/Work/repo/libs/libmesh/openMPI/libmesh-1.2.0'
make: *** [Makefile.openmpi:28: build] Error 2
87.934u 15.745s 0:55.97 185.2%  0+0k 51736+664688io 65pf+0w

I googled it, looks like it is a known issue, but I do not know how to 
proceed. Can I simply avoid netcdf build?

I attach my configuration log.

Thank you,

Michael.

Re: [Libmesh-users] Should I move to FEMSystem?

[Paul T. B. <ptb...@gm...>]

On Fri, Dec 15, 2017 at 2:00 PM, Renato Poli <re...@gm...> wrote:

> Hi
>
> So far I am using the "introduction" style to solve a linear system of
> equations.
> I attach a assemble function, increment timestep and march.
>
> Things are getting more complex, though.
> I'm starting to look into adaptative meshing and non linearity, and
> the code is getting sort of dirty.
> I can reorganize things, that would help, but I consider rewrite using
> FEMSystem.
> Does not seem simple, but looks powerful.
>
> Questions:
> - Is FEMSystem the best way to move forward?
>

It's certainly one option. It could simplify some aspects, particularly
unsteady vs. steady solves, etc. You'd still need to worry about
adaptivity, but most other things will be contained to element level
quantities with FEMSystem.


> - Is there any other possibility I should be aware of?
>

There is a project called GRINS (https://github.com/grinsfem/grins) that
Roy and I develop (mostly myself and my students these days) that is built
around FEMSystem for facilitating multiphysics FEM analysis. It could be
useful and has a few nice carrots. A much larger project that heavily
leverages libMesh is called MOOSE (https://github.com/idaholab/moose); it
could also be useful for multiphysics applications. MOOSE doesn't leverage
FEMSystem per se, but is an excellent package with a lot of support.

If you have questions about GRINS, please feel free to contact me off list.

Hope that helps.


>
> 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] Should I move to FEMSystem?

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

Hi

So far I am using the "introduction" style to solve a linear system of
equations.
I attach a assemble function, increment timestep and march.

Things are getting more complex, though.
I'm starting to look into adaptative meshing and non linearity, and
the code is getting sort of dirty.
I can reorganize things, that would help, but I consider rewrite using
FEMSystem.
Does not seem simple, but looks powerful.

Questions:
- Is FEMSystem the best way to move forward?
- Is there any other possibility I should be aware of?

Thanks,
Renato

Re: [Libmesh-users] Question about hybrid mesh

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

On Thu, 14 Dec 2017, Viviana Palacio Betancur wrote:

> Thank you! I was able to fix my problem.
> I was creating the quadrature rule before looping over the elements. Thus, "ERROR: Unsupported type: 4" appeared when the TRI6 elements appeared.
> I fixed this by creating the quadrature rule and building the FEBase within the element loop. 

I wouldn't recommend that in the long run, for performance reasons.
The best thing to do currently is to create an FE for each dimension,
or to use FEMContext which does that under the hood.

For small problems or prototype code you should be fine, though.
---
Roy

Re: [Libmesh-users] Question about hybrid mesh

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

Hi Roy,

Thank you! I was able to fix my problem.

I was creating the quadrature rule before looping over the elements. Thus,
"ERROR: Unsupported type: 4" appeared when the TRI6 elements appeared. I
fixed this by creating the quadrature rule and building the FEBase within
the element loop.

Best,
Viviana.


On Thu, Dec 14, 2017 at 9:03 AM, Roy Stogner <roy...@ic...>
wrote:

>
> On Wed, 13 Dec 2017, Viviana Palacio Betancur wrote:
>
> I am trying to assemble the system's matrix for a mesh composed of TET10
>> (bulk) bounded by TRI6 (surface) elements but I get an error related to an
>> unsupported type of elements. The problem solves for a single variable.
>>
>
> This should be fine.  We do something similar in fem_system_ex4.
>
> When I try to assemble the matrix, I get the error: *"ERROR:
>> Unsupported type: 4."*
>>
>
> You'll understand that error better if you look at the line number or
> the full stack trace to get context.
>
> I don't understand if I should create separate quadrature rules
>> because there are two types of elements.
>>
>
> You'll need separate quadrature rules incidentally, because you'll
> need separate FE objects (note that they're templated around element
> dimension) and each FE object will need its own quadrature rule.
>
> But then the elements are attached to the same variable, so how
>> would I be able to distinguish between them?
>>
>
> You can test Elem::dim() for each.
> ---
> Roy
>

Re: [Libmesh-users] Question about hybrid mesh

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

On Wed, 13 Dec 2017, Viviana Palacio Betancur wrote:

> I am trying to assemble the system's matrix for a mesh composed of TET10
> (bulk) bounded by TRI6 (surface) elements but I get an error related to an
> unsupported type of elements. The problem solves for a single variable.

This should be fine.  We do something similar in fem_system_ex4.

> When I try to assemble the matrix, I get the error: *"ERROR:
> Unsupported type: 4."*

You'll understand that error better if you look at the line number or
the full stack trace to get context.

> I don't understand if I should create separate quadrature rules
> because there are two types of elements.

You'll need separate quadrature rules incidentally, because you'll
need separate FE objects (note that they're templated around element
dimension) and each FE object will need its own quadrature rule.

> But then the elements are attached to the same variable, so how
> would I be able to distinguish between them?

You can test Elem::dim() for each.
---
Roy

[Libmesh-users] Question about hybrid mesh

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

Hi,

I am trying to assemble the system's matrix for a mesh composed of TET10
(bulk) bounded by TRI6 (surface) elements but I get an error related to an
unsupported type of elements. The problem solves for a single variable.

I create my meshes using CUBIT and export it in in exodus format: 1. Create
the volume and mesh. 2. Create 2 blocks, one for the volume and one for the
surface. 3. Give an element type to each block.

In my program, libmesh recognizes both subdomains with the ids I gave in
CUBIT. When I try to assemble the matrix, I get the error:
*"ERROR: Unsupported type: 4."* I don't understand if I should create
separate quadrature rules because there are two types of elements. But then
the elements are attached to the same variable, so how would I be able to
distinguish between them?

Thanks in advance. Best,

Viviana.

Re: [Libmesh-users] how to read a distributed mesh

[Jahrul A. <al...@mu...>]

Ok, I have created a simpler example.

1) CheckpointWrite.png -- screenshot showing the output when writing the
mesh.

2) CheckpointRead.png -- screenshot showing the output when reading the mesh

You can see exactly what I wrote in my earlier email, albeit with different
numbers this time.

3) Checkpoint.cxx  - a quick code. You have to use #if  0 segment to read
lshaped.xda, refine it, and save as Checkpoint format. Then change to #if 1
to read the "cp" mesh. I am assuming, AMR mesh will work, if this works for
read/write.

Many thanks for your help.

Regards,

Jahrul



=====================================
Jahrul Alam, PhD
Associate Professor, Dept of Mathematics and Statistics
Memorial University, St John's, NL, Canada
http://www.math.mun.ca/~alamj/
eMail: al...@mu...
Office: HH-3054, Tel: 709-864 8071
=====================================

On Tue, Dec 12, 2017 at 11:39 AM, Roy Stogner <roy...@ic...>
wrote:

>
> On Tue, 12 Dec 2017, Jahrul Alam wrote:
>
> First, I wrote the mesh as     [CheckpointIO(mymesh).write("test.cp");]
>>
>> Next, I re-compiled the code (only to change 'read' to 'write'), and read
>> the mesh as     [CheckpointIO(mymesh).read("test.cp");]
>>
>> mymesh.print_info() shows n_nodes=33153, n_local_nodes = 4225,
>> n_partitions=8, n_processors=8 before it was written. However, I get
>> n_nodes = 4225
>> and n_local_nodes = 4225, n_partitions=1, n_processors=8 afterwards.
>>
>> Am I missing something?
>>
>
> Either you are or I am.  Can you send me a short code that replicates
> the problem for you?
>
> Thanks,
>
> ---
> Roy
> ------------------------------------------------------------
> ------------------
> 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
>

Re: [Libmesh-users] Euler Beam Equation Using Reduced Basis

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

I suggest you first get an example working using a standard finite element
implementation (e.g. based on one of the "systems_of_equations" examples).
Once you have that working you can then try to convert it into a reduced
basis implementation. But note that normally reduced basis is not used for
1D models since those models are generally fast enough to solve without any
model reduction. A better case to consider might be 3D elasticity.

David

On Tue, Dec 12, 2017 at 8:10 PM, 강신성 <ss...@pu...> wrote:

>
>
>
>   Hello everyone,
>
>
>
>   I want to solve the Euler cantilever beam equation using reduced basis
> to understand the RB method.
>
>   However, I don't know how to deal with a 2nd derivative term of a weak
> form of the Euler beam equation.
>
>
>
>   First, I created a 1D mesh. Then, refferring to the RB examples, I made
> a basic RB code.
>
>   After that, I tried to use "SECOND" variable and "d2phi" in the RB code,
> but I can't solve it. The error message is as follows.
>   ============================================================
> =====================
>
>   ***************************************************************
> * Running App  run_Beam_Euler-opt
> ***************************************************************
>
> ./run_Beam_Euler-opt  2&gt;&amp;1 | tee output.txt
>  Mesh Information:
>   elem_dimensions()={1}
>   spatial_dimension()=2
>   n_nodes()=15
>     n_local_nodes()=15
>   n_elem()=7
>     n_local_elem()=7
>     n_active_elem()=7
>   n_subdomains()=1
>   n_partitions()=1
>   n_processors()=1
>   n_threads()=1
>   processor_id()=0
>
>  EquationSystems
>   n_systems()=1
>    System #0, "RBElasticity"
>     Type "RBConstruction"
>     Variables="u"
>     Finite Element Types="LAGRANGE"
>     Approximation Orders="SECOND"
>     n_dofs()=15
>     n_local_dofs()=15
>     n_constrained_dofs()=1
>     n_local_constrained_dofs()=1
>     n_vectors()=1
>     n_matrices()=1
>     DofMap Sparsity
>       Average  On-Processor Bandwidth &lt;= 3.8
>       Average Off-Processor Bandwidth &lt;= 0
>       Maximum  On-Processor Bandwidth &lt;= 5
>       Maximum Off-Processor Bandwidth &lt;= 0
>     DofMap Constraints
>       Number of DoF Constraints = 1
>       Average DoF Constraint Length= 0
>
> Initializing training parameters with random training set...
> Parameter length: log scaling = 0
> Parameter load: log scaling = 0
> Parameter point_load: log scaling = 0
>
> RBConstruction parameters:
> system name: RBElasticity
> Nmax: 20
> Greedy relative error tolerance: 0.001
> Greedy absolute error tolerance: 1e-12
> Do we normalize RB error bound in greedy? 0
> Aq operators attached: 1
> Fq functions attached: 1
> n_outputs: 0
> Number of parameters: 3
> Parameter length: Min = 1, Max = 20
> Parameter load: Min = -5, Max = 5
> Parameter point_load: Min = -5, Max = 5
> n_training_samples: 1000
> quiet mode? 1
>
> Assembling inner product matrix
> *** Warning, This code is untested, experimental, or likely to see future
> API changes: src/systems/dg_fem_context.C, line 35, compiled Aug 25 2017 at
> 02:20:14 ***
> Assembling affine operator 1 of 1
> Assembling affine vector 1 of 1
> Convergence error. Error id: -11
> Stack frames: 8
> 0: libMesh::print_trace(std::ostream&amp;)
> 1: libMesh::MacroFunctions::report_error(char const*, int, char const*,
> char const*)
> 2: libMesh::RBConstruction::check_convergence(libMesh::
> LinearSolver&lt;double&gt;&amp;)
> 3: libMesh::RBConstruction::compute_Fq_representor_innerprods(bool)
> 4: libMesh::RBConstruction::train_reduced_basis(bool)
> 5: ./run_Beam_Euler-opt() [0x416482]
> 6: __libc_start_main
> 7: ./run_Beam_Euler-opt() [0x416ed9]
> [0] src/reduced_basis/rb_construction.C, line 2124, compiled Aug 25 2017
> at 02:17:58
> application called MPI_Abort(MPI_COMM_WORLD, 1) - process 0
> [unset]: aborting job:
> application called MPI_Abort(MPI_COMM_WORLD, 1) - process 0
> ============================================================
> =====================
>
>
>   I wonder if this is right way. If not, I want to know another way to
> solve the Euler cantilever beam equation.
>
>
>
>   Best regards,
>
>   S. Kang.
>
>
> ------------------------------------------------------------
> ------------------
> 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] Euler Beam Equation Using Reduced Basis

[강신성 <ss...@pu...>]

 
  
  Hello everyone,
 
  
 
  I want to solve the Euler cantilever beam equation using reduced basis to understand the RB method.
 
  However, I don't know how to deal with a 2nd derivative term of a weak form of the Euler beam equation.
 
  
 
  First, I created a 1D mesh. Then, refferring to the RB examples, I made a basic RB code. 
 
  After that, I tried to use "SECOND" variable and "d2phi" in the RB code, but I can't solve it. The error message is as follows. 
  =================================================================================
 
  ***************************************************************
* Running App  run_Beam_Euler-opt
***************************************************************
 
./run_Beam_Euler-opt  2>&1 | tee output.txt
 Mesh Information:
  elem_dimensions()={1}
  spatial_dimension()=2
  n_nodes()=15
    n_local_nodes()=15
  n_elem()=7
    n_local_elem()=7
    n_active_elem()=7
  n_subdomains()=1
  n_partitions()=1
  n_processors()=1
  n_threads()=1
  processor_id()=0

 EquationSystems
  n_systems()=1
   System #0, "RBElasticity"
    Type "RBConstruction"
    Variables="u" 
    Finite Element Types="LAGRANGE" 
    Approximation Orders="SECOND" 
    n_dofs()=15
    n_local_dofs()=15
    n_constrained_dofs()=1
    n_local_constrained_dofs()=1
    n_vectors()=1
    n_matrices()=1
    DofMap Sparsity
      Average  On-Processor Bandwidth <= 3.8
      Average Off-Processor Bandwidth <= 0
      Maximum  On-Processor Bandwidth <= 5
      Maximum Off-Processor Bandwidth <= 0
    DofMap Constraints
      Number of DoF Constraints = 1
      Average DoF Constraint Length= 0

Initializing training parameters with random training set...
Parameter length: log scaling = 0
Parameter load: log scaling = 0
Parameter point_load: log scaling = 0

RBConstruction parameters:
system name: RBElasticity
Nmax: 20
Greedy relative error tolerance: 0.001
Greedy absolute error tolerance: 1e-12
Do we normalize RB error bound in greedy? 0
Aq operators attached: 1
Fq functions attached: 1
n_outputs: 0
Number of parameters: 3
Parameter length: Min = 1, Max = 20
Parameter load: Min = -5, Max = 5
Parameter point_load: Min = -5, Max = 5
n_training_samples: 1000
quiet mode? 1

Assembling inner product matrix
*** Warning, This code is untested, experimental, or likely to see future API changes: src/systems/dg_fem_context.C, line 35, compiled Aug 25 2017 at 02:20:14 ***
Assembling affine operator 1 of 1
Assembling affine vector 1 of 1
Convergence error. Error id: -11
Stack frames: 8
0: libMesh::print_trace(std::ostream&)
1: libMesh::MacroFunctions::report_error(char const*, int, char const*, char const*)
2: libMesh::RBConstruction::check_convergence(libMesh::LinearSolver<double>&)
3: libMesh::RBConstruction::compute_Fq_representor_innerprods(bool)
4: libMesh::RBConstruction::train_reduced_basis(bool)
5: ./run_Beam_Euler-opt() [0x416482]
6: __libc_start_main
7: ./run_Beam_Euler-opt() [0x416ed9]
[0] src/reduced_basis/rb_construction.C, line 2124, compiled Aug 25 2017 at 02:17:58
application called MPI_Abort(MPI_COMM_WORLD, 1) - process 0
[unset]: aborting job:
application called MPI_Abort(MPI_COMM_WORLD, 1) - process 0
================================================================================= 
  
 
  I wonder if this is right way. If not, I want to know another way to solve the Euler cantilever beam equation.
 
  
 
  Best regards,
 
  S. Kang.
 
 

Re: [Libmesh-users] how to read a distributed mesh

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

On Tue, 12 Dec 2017, Jahrul Alam wrote:

> First, I wrote the mesh as     [CheckpointIO(mymesh).write("test.cp");]
> 
> Next, I re-compiled the code (only to change 'read' to 'write'), and read the mesh as     [CheckpointIO(mymesh).read("test.cp");]
> 
> mymesh.print_info() shows n_nodes=33153, n_local_nodes = 4225, n_partitions=8, n_processors=8 before it was written. However, I get n_nodes = 4225
> and n_local_nodes = 4225, n_partitions=1, n_processors=8 afterwards. 
> 
> Am I missing something?

Either you are or I am.  Can you send me a short code that replicates
the problem for you?

Thanks,
---
Roy

Re: [Libmesh-users] how to read a distributed mesh

[Jahrul A. <al...@mu...>]

First, I wrote the mesh as     [CheckpointIO(mymesh).write("test.cp");]

Next, I re-compiled the code (only to change 'read' to 'write'), and read
the mesh as     [CheckpointIO(mymesh).read("test.cp");]

mymesh.print_info() shows n_nodes=33153, n_local_nodes = 4225,
n_partitions=8, n_processors=8 before it was written. However, I get
n_nodes = 4225 and n_local_nodes = 4225, n_partitions=1, n_processors=8
afterwards.

Am I missing something?





On Mon, Dec 11, 2017 at 8:35 AM, Roy Stogner <roy...@ic...>
wrote:

>
> On Sat, 9 Dec 2017, Jahrul Alam wrote:
>
> Nemesis IO reads the mesh in parallel (not the solution); however,
>> the reader destroys the multi-level structure of the mesh. Is there
>> a work around to handle this problem?
>>
>
> I'm afraid not; not even ExodusII ("serial Nemesis") lets us store AMR
> structure.  IIRC when we tried the result was awful on visualization
> programs, which would try to display the inactive elements too and
> naturally show garbage.  https://en.wikipedia.org/wiki/Z-fighting
>
> For archival of AMR meshes our only good solution right now is
> serialized Xdr, I believe.  If that's a performance problem, you could
> output CheckpointIO during your simulation runs, then postprocess
> convert to Xdr later.  At some point we'll also make CheckpointIO a
> first-class format with forwards compatibility, but that's a pain to
> maintain while the format is still in flux so it won't happen soon.
>
> ---
> Roy
>
> ------------------------------------------------------------
> ------------------
> 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
>



-- 
=====================================
Jahrul Alam, PhD
Assistant Professor, Dept of Mathematics and Statistics
Memorial University, St John's, NL, Canada
http://www.math.mun.ca/~alamj/
eMail: al...@mu...
Office: HH-3035, Tel: 709-737 8071
=====================================

Re: [Libmesh-users] how to read a distributed mesh

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

On Sat, 9 Dec 2017, Jahrul Alam wrote:

> Nemesis IO reads the mesh in parallel (not the solution); however,
> the reader destroys the multi-level structure of the mesh. Is there
> a work around to handle this problem?

I'm afraid not; not even ExodusII ("serial Nemesis") lets us store AMR
structure.  IIRC when we tried the result was awful on visualization
programs, which would try to display the inactive elements too and
naturally show garbage.  https://en.wikipedia.org/wiki/Z-fighting

For archival of AMR meshes our only good solution right now is
serialized Xdr, I believe.  If that's a performance problem, you could
output CheckpointIO during your simulation runs, then postprocess
convert to Xdr later.  At some point we'll also make CheckpointIO a
first-class format with forwards compatibility, but that's a pain to
maintain while the format is still in flux so it won't happen soon.
---
Roy

Re: [Libmesh-users] how to read a distributed mesh

[Jahrul A. <al...@mu...>]

Hello,

Nemesis IO reads the mesh in parallel (not the solution); however, the
reader destroys the multi-level structure of the mesh. Is there a work
around to handle this problem?

Regards,

Jahrul

On Mon, Dec 4, 2017 at 3:40 PM, Roy Stogner <roy...@ic...>
wrote:

>
> On Mon, 4 Dec 2017, John Peterson wrote:
>
> On Mon, Dec 4, 2017 at 10:59 AM, Alam, Jahrul <al...@mu...> wrote:
>>
>> Thanks for the clarification. Can you suggest a work around? If I do,
>>> mesh0.read(lshaped_0.vtu) and mesh1.read(lshaped_1.vtu), and so on, is it
>>> possible to end up with a DistributedMesh by combining mesh0,
>>> mesh1,............. at the user level?
>>>
>>> Or, is there another format that supports parallel read and write?
>>>
>>
>> I wouldn't worry about parallel read/write until you get to a point that
>> you are working with a Mesh that's too big to even be opened on one
>> processor.
>>
>> Your code can still run in parallel even when you read a mesh in serial.
>>
>
> For the sake of completeness, I'll point out that you can read and
> write distributed meshes in either the standard Nemesis format or in
> a libMesh-specific (and libMesh-version-specific! beware!)
> "Checkpoint" format.  (Our libMesh-specific XDR format let you write
> solution data in parallel, but not mesh data currently)
>
> I would definitely suggest taking John's advice, though.  For archival
> purposes of final solutions, serialized mesh files are just easier to
> deal with.  Parallel mesh files become useful when you have so much
> data to write out (transient problem with a good solver with which you
> want to make a movie?) that I/O becomes a bottleneck.
> ---
> Roy
>
>
> ------------------------------------------------------------
> ------------------
> 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
>



-- 
=====================================
Jahrul Alam, PhD
Assistant Professor, Dept of Mathematics and Statistics
Memorial University, St John's, NL, Canada
http://www.math.mun.ca/~alamj/
eMail: al...@mu...
Office: HH-3035, Tel: 709-737 8071
=====================================

[Libmesh-users] (almost) no changes when adding a Lagrange Multiplier

[Hubert W. <hub...@gm...>]

Dear all,
I tried to add a Lagrange multiplier to the miscellaneous_ex14, but it 
doesn't change anything. Maybe it is a stupid error I have, but I have 
no clue what exactly to change.
What I expect to do is to add a Lagrange multiplier that sets the 
solution to 0 at all elements at radius >=4 units.
The changes I applied can be found at
https://gist.github.com/BalticPinguin/6a4d7a5c81b41e6ffd932ceb4548163c 
<https://www.xemail.de/deref.php?https://gist.github.com/BalticPinguin/6a4d7a5c81b41e6ffd932ceb4548163c>

Can someone please help me, what I am doing wrong? According to the 
example systems_of_equations_3 and _5, it doesn't look actually too 
complicated.

Many thanks in advance,
Hubert

Re: [Libmesh-users] how to read a distributed mesh

[Jahrul A. <al...@mu...>]

Hello, Roy and John,

Thank you very much for your feedback. Yes, I am working with a mesh that
is too big. Either a mesh of 1024^3 cells or a mesh of 256^3 cells that is
further refined adaptively to get a local resolution of 1024^3. It can be
opened on a single processor subject to the available memory but I like to
read and write in parallel, having the mesh distributed at each time step.
Even with a smaller mesh, it is question of "algorithmic" view, if I can do
so, and if I can utilize libMesh for this. I fully understand John's work
around.

I agree with Roy that serialized meshes are sometimes useful. However, I
need to deal with a large mesh and associated solution vector, and read the
transient data for post-processing purpose - for which parallel read/write
is useful.

If I understood Roy, I could use either Nemesis format or Checkpoint format
for parallel read/write. Please correct me if this is NOT the case. I will
try these two formats.

Thank you very much for helping computational researchers with the libMesh
package.

Regards,

Jahrul




On Mon, Dec 4, 2017 at 3:40 PM, Roy Stogner <roy...@ic...>
wrote:

>
> On Mon, 4 Dec 2017, John Peterson wrote:
>
> On Mon, Dec 4, 2017 at 10:59 AM, Alam, Jahrul <al...@mu...> wrote:
>>
>> Thanks for the clarification. Can you suggest a work around? If I do,
>>> mesh0.read(lshaped_0.vtu) and mesh1.read(lshaped_1.vtu), and so on, is it
>>> possible to end up with a DistributedMesh by combining mesh0,
>>> mesh1,............. at the user level?
>>>
>>> Or, is there another format that supports parallel read and write?
>>>
>>
>> I wouldn't worry about parallel read/write until you get to a point that
>> you are working with a Mesh that's too big to even be opened on one
>> processor.
>>
>> Your code can still run in parallel even when you read a mesh in serial.
>>
>
> For the sake of completeness, I'll point out that you can read and
> write distributed meshes in either the standard Nemesis format or in
> a libMesh-specific (and libMesh-version-specific! beware!)
> "Checkpoint" format.  (Our libMesh-specific XDR format let you write
> solution data in parallel, but not mesh data currently)
>
> I would definitely suggest taking John's advice, though.  For archival
> purposes of final solutions, serialized mesh files are just easier to
> deal with.  Parallel mesh files become useful when you have so much
> data to write out (transient problem with a good solver with which you
> want to make a movie?) that I/O becomes a bottleneck.
> ---
> Roy
>
>
> ------------------------------------------------------------
> ------------------
> 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
>



-- 
=====================================
Jahrul Alam, PhD
Assistant Professor, Dept of Mathematics and Statistics
Memorial University, St John's, NL, Canada
http://www.math.mun.ca/~alamj/
eMail: al...@mu...
Office: HH-3035, Tel: 709-737 8071
=====================================

Re: [Libmesh-users] how to read a distributed mesh

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

On Mon, 4 Dec 2017, John Peterson wrote:

> On Mon, Dec 4, 2017 at 10:59 AM, Alam, Jahrul <al...@mu...> wrote:
>
>> Thanks for the clarification. Can you suggest a work around? If I do,
>> mesh0.read(lshaped_0.vtu) and mesh1.read(lshaped_1.vtu), and so on, is it
>> possible to end up with a DistributedMesh by combining mesh0,
>> mesh1,............. at the user level?
>>
>> Or, is there another format that supports parallel read and write?
>
> I wouldn't worry about parallel read/write until you get to a point that
> you are working with a Mesh that's too big to even be opened on one
> processor.
>
> Your code can still run in parallel even when you read a mesh in serial.

For the sake of completeness, I'll point out that you can read and
write distributed meshes in either the standard Nemesis format or in
a libMesh-specific (and libMesh-version-specific! beware!)
"Checkpoint" format.  (Our libMesh-specific XDR format let you write
solution data in parallel, but not mesh data currently)

I would definitely suggest taking John's advice, though.  For archival
purposes of final solutions, serialized mesh files are just easier to
deal with.  Parallel mesh files become useful when you have so much
data to write out (transient problem with a good solver with which you
want to make a movie?) that I/O becomes a bottleneck.
---
Roy

Re: [Libmesh-users] how to read a distributed mesh

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

On Mon, Dec 4, 2017 at 10:59 AM, Alam, Jahrul <al...@mu...> wrote:

> Hi John,
>
> Thanks for the clarification. Can you suggest a work around? If I do,
> mesh0.read(lshaped_0.vtu) and mesh1.read(lshaped_1.vtu), and so on, is it
> possible to end up with a DistributedMesh by combining mesh0,
> mesh1,............. at the user level?
>
> Or, is there another format that supports parallel read and write?
>

I wouldn't worry about parallel read/write until you get to a point that
you are working with a Mesh that's too big to even be opened on one
processor.

Your code can still run in parallel even when you read a mesh in serial.

-- 
John

Re: [Libmesh-users] how to read a distributed mesh

[Jahrul A. <al...@mu...>]

Hi John,

Thanks for the clarification. Can you suggest a work around? If I do, for
example, mesh0.read(lshaped_0.vtu) and mesh1.read(lshaped_1.vtu), and so
on, is it possible to end up with a DistributedMesh by combining mesh0,
mesh1,............. at the user level?

Or, is there another format that supports parallel read and write?

Regards,

Jahrul

On Mon, Dec 4, 2017 at 12:19 PM, John Peterson <jwp...@gm...> wrote:

> On Sat, Dec 2, 2017 at 6:49 PM, Jahrul Alam <al...@mu...> wrote:
>
> > Hello,
> >
> > I am having a problem with reading a mesh. As a test case, I create a
> Mesh,
> > and save the mesh:
> >
> > lshaped_mesh.wite("lshaped.pvtu").
> >
> > Running with 4 processes, I get five files: lshaped.pvtu, lshaped_0.vtu,
> > lshaped_1.vtu, lshaped_2.vtu, and lshaped_3.vtu.
> >
> > Now, I cannot read the saved mesh:
> >
> > lshaped_mesh.read("lshaped.pvtu")
> >
> > throws an error, such as "pvtu is not recognized".
> >
> > Is there a way that I can read distributed mesh from a file?
> >
>
> Unfortunately, we don't currently support reading parallel VTK files, only
> writing them.
>
> --
> John
> ------------------------------------------------------------
> ------------------
> 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
>



-- 
=====================================
Jahrul Alam, PhD
Assistant Professor, Dept of Mathematics and Statistics
Memorial University, St John's, NL, Canada
http://www.math.mun.ca/~alamj/
eMail: al...@mu...
Office: HH-3035, Tel: 709-737 8071
=====================================

Re: [Libmesh-users] how to read a distributed mesh

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

On Sat, Dec 2, 2017 at 6:49 PM, Jahrul Alam <al...@mu...> wrote:

> Hello,
>
> I am having a problem with reading a mesh. As a test case, I create a Mesh,
> and save the mesh:
>
> lshaped_mesh.wite("lshaped.pvtu").
>
> Running with 4 processes, I get five files: lshaped.pvtu, lshaped_0.vtu,
> lshaped_1.vtu, lshaped_2.vtu, and lshaped_3.vtu.
>
> Now, I cannot read the saved mesh:
>
> lshaped_mesh.read("lshaped.pvtu")
>
> throws an error, such as "pvtu is not recognized".
>
> Is there a way that I can read distributed mesh from a file?
>

Unfortunately, we don't currently support reading parallel VTK files, only
writing them.

-- 
John

[Libmesh-users] how to read a distributed mesh

[Jahrul A. <al...@mu...>]

Hello,

I am having a problem with reading a mesh. As a test case, I create a Mesh,
and save the mesh:

lshaped_mesh.wite("lshaped.pvtu").

Running with 4 processes, I get five files: lshaped.pvtu, lshaped_0.vtu,
lshaped_1.vtu, lshaped_2.vtu, and lshaped_3.vtu.

Now, I cannot read the saved mesh:

lshaped_mesh.read("lshaped.pvtu")

throws an error, such as "pvtu is not recognized".

Is there a way that I can read distributed mesh from a file?

Thanks,

Jahrul



-- 
=====================================
Jahrul Alam, PhD
Assistant Professor, Dept of Mathematics and Statistics
Memorial University, St John's, NL, Canada
http://www.math.mun.ca/~alamj/
eMail: al...@mu...
Office: HH-3035, Tel: 709-737 8071
=====================================

Re: [Libmesh-users] (no subject)

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

On Tue, 28 Nov 2017, Zack Vitoh wrote:

> *Question 2*
> For the cases above, I noticed that I am no longer running libmesh in
> parallel when I read in the mesh.  I found, and tried to use
> libMesh::Partitioner part();
> // Partitioner()::partition_unpartitioned_elements(mesh);
> // Partitioner.partition_unpartitioned_elements(mesh);
>
> but I am not sure how exactly this works.  Also, I am not sure if using
> this the right approach?

Nope.  The right approach for most users is to do nothing!  In theory,
you just read in your file the same way you would in serial, and if
you're running in parallel then libMesh will automatically partition
the Mesh over the ranks in the communicator you used for it.

> *Question 3*
> This is less important, as I may have sidestepped this for now, but I'm
> sure it will return with a vengeance.
> I looked through the forums to find out how VTKIO::write_nodal_data works,
> and from there looked into the source for VTKIO::write_equation_system to
> see if I could figure out how the former is used in the latter, but to no
> avail.  I'm writing using exo_io.write_timestep for now, but my screen
> (rightly?) reprimands me for doing so.
> I have a sense that this will involve a host of other functions
> (allgather?) so I may send this as a separate email question.

I don't use VTKIO myself, but IIRC it's supposed to be pretty easy: a
line from our example files like

VTKIO (mesh).write_equation_systems ("out.pvtu", equation_systems);

reads your EquationSystems' data and handles the parallel
synchronization (If necessary?  I think pvtu is a parallel output
format...) and so itself.
---
Roy