[Libmesh-users] matrix nonzero I-J locations

[Manav Bhatia]

Hi, 

   Is there a quick way to get the non-zero locations of a matrix? I am using 
libMesh with PETSc. 

   I am not sure if there is one in libMesh. The function in PETSc seems to 
only work for sequential matrices 
(https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/MatGetRowIJ.html).

Regards,
Manav

___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] problem with inverse_map()

[Manav Bhatia]

Roy, 

   This turned out to be unrelated to adaptivity. 

I am working on immersed boundary problems where I cut a FE based on a 
level-set function. On each element obtained by the cut operation, I ask the FE 
to be initialized, either using a quadrature rule, or by specific in the QP 
locations. 

While this forward operation of QP -> compute shape functions, derivatives 
and normals (on sides) should work out fine, the issue is showing up in  
compute_face_map() ( 
https://github.com/libMesh/libmesh/blob/c4c9fd5450489486fd5f7baf2ec9a8ac0d47fc99/src/fe/fe_boundary.C#L224
 
<https://github.com/libMesh/libmesh/blob/c4c9fd5450489486fd5f7baf2ec9a8ac0d47fc99/src/fe/fe_boundary.C#L224>
 ).

It appears that compute_face_map() is using the xyz locations of the 
quadrature points to figure out non-dimensional location of the quadrature 
points here:  
https://github.com/libMesh/libmesh/blob/c4c9fd5450489486fd5f7baf2ec9a8ac0d47fc99/src/fe/fe_boundary.C#L754
 
<https://github.com/libMesh/libmesh/blob/c4c9fd5450489486fd5f7baf2ec9a8ac0d47fc99/src/fe/fe_boundary.C#L754>
 

 So, every once in a while the level-set based intersection leads to sliver 
cut-cells, which case this inverse-map method to fail. 

 I am guessing there is a reason to do things this way, even though the 
user may have explicitly provided the quadrature points to begin with. Do you 
know if there is a way to bypass the inverse_map for FE reinit? 

Thanks,
Manav

   

> On May 2, 2019, at 8:10 AM, Stogner, Roy H  wrote:
> 
> 
> On Thu, 2 May 2019, Manav Bhatia wrote:
> 
>> I ran the debug version and this is where it crashed. 
> 
> Well, I'm afraid that's no more help.  Thanks anyway.
> 
> Could you loop through elem 16514's parent (672) and parent's parent
> and so on up to the top level and print them?  I'm not sure where to
> begin looking for the problem, unless you can set up a test case we
> can reproduce.
> ---
> Roy
> 
>> [2] src/fe/fe_map.C, line 1866, compiled Apr 29 2019 at 13:59:12
>> WARNING: Newton scheme has not converged in 11 iterations:
>>physical_point=(x,y,z)=(0.27,   0.2775,0)   
>> physical_guess=(x,y,z)=(0.27,   0.2775,0)   
>> dp=(x,y,z)=(-1.21944e-13,
>> -1.12163e-06,0)   p=(x,y,z)=(  -1, -0.57735,0)   
>> error=1.12163e-06   in element 16514
>>   Elem Information
>>id()=16514, processor_id()=2
>>type()=QUAD4
>>dim()=2
>>n_nodes()=4
>> 0  Node id()=13234, processor_id()=4294967295, Point=(x,y,z)=(0.27,  
>>  0.2775,0)
>> DoFs=
>> 1  Node id()=604, processor_id()=2, Point=(x,y,z)=(0.271875,   0.2775,   
>>  0)
>> DoFs=(0/0/13470) (0/1/13471) (0/2/13472) (0/3/13473) (0/4/13474) 
>> (0/5/13475) (2/0/2245) (3/0/2245) 
>> 2  Node id()=13235, processor_id()=4294967295, Point=(x,y,z)=(0.271875,  
>>  0.2775,0)
>> DoFs=
>> 3  Node id()=13233, processor_id()=4294967295, Point=(x,y,z)=(0.27,  
>>  0.2775,0)
>> DoFs=
>>n_sides()=4
>> neighbor(0)=nullptr
>> neighbor(1)=nullptr
>> neighbor(2)=nullptr
>> neighbor(3)=nullptr
>>hmin()=9.89829e-11, hmax()=0.001875
>>volume()=1.85593e-13
>>active()=1, ancestor()=0, subactive()=0, has_children()=0
>>parent()=672
>>level()=4, p_level()=0
>>refinement_flag()=DO_NOTHING
>>p_refinement_flag()=DO_NOTHING
>>DoFs=
>> [2] src/fe/fe_map.C, line 1866, compiled Apr 29 2019 at 13:59:12
>> WARNING: Newton scheme has not converged in 12 iterations:
>>physical_point=(x,y,z)=(0.27,   0.2775,0)   
>> physical_guess=(x,y,z)=(0.27,   0.2775,0)   
>> dp=(x,y,z)=(-1.21944e-13,
>> -1.12163e-06,0)   p=(x,y,z)=(  -1, -0.577351,0)   
>> error=1.12163e-06   in element 16514
>>   Elem Information
>>id()=16514, processor_id()=2
>>type()=QUAD4
>>dim()=2
>>n_nodes()=4
>> 0  Node id()=13234, processor_id()=4294967295, Point=(x,y,z)=(0.27,  
>>  0.2775,0)
>> DoFs=
>> 1  Node id()=604, processor_id()=2, Point=(x,y,z)=(0.271875,   0.2775,   
>>  0)
>> DoFs=(0/0/13470) (0/1/13471) (0/2/13472) (0/3/13473) (0/4/13474) 
>> (0/5/13475) (2/0/2245) (3/0/2245) 
>> 2  Node id()=13235, processor_id()=4294967295, Point=(x,y,z)=(0.271875,  
>>  0.2775,0)
>> DoFs=
>> 3  Node id()=13233, processor_id()=4294967295, Point=(x,y,z)=(0.27,  
>>  0.2775,0)
>> DoFs=
>>n_sides()=4
>> neighbor(0)=nullptr
>> neighbor(1)=nullptr
>> neighbor(2)=

Re: [Libmesh-users] problem with inverse_map()

[Manav Bhatia]

/13471) (0/2/13472) (0/3/13473) (0/4/13474) 
(0/5/13475) (2/0/2245) (3/0/2245) 
2  Node id()=13235, processor_id()=4294967295, Point=(x,y,z)=(0.271875,   
0.2775,0)
DoFs=
3  Node id()=13233, processor_id()=4294967295, Point=(x,y,z)=(0.27,   
0.2775,0)
DoFs=
   n_sides()=4
neighbor(0)=nullptr
neighbor(1)=nullptr
neighbor(2)=nullptr
neighbor(3)=nullptr
   hmin()=9.89829e-11, hmax()=0.001875
   volume()=1.85593e-13
   active()=1, ancestor()=0, subactive()=0, has_children()=0
   parent()=672
   level()=4, p_level()=0
   refinement_flag()=DO_NOTHING
   p_refinement_flag()=DO_NOTHING
   DoFs=
ERROR: Newton scheme FAILED to converge in 21 iterations in element 16514 for 
physical point = (x,y,z)=(0.27,   0.2775,0)
  Elem Information
   id()=16514, processor_id()=2
   type()=QUAD4
   dim()=2
   n_nodes()=4
0  Node id()=13234, processor_id()=4294967295, Point=(x,y,z)=(0.27,   
0.2775,0)
DoFs=
1  Node id()=604, processor_id()=2, Point=(x,y,z)=(0.271875,   0.2775,  
  0)
DoFs=(0/0/13470) (0/1/13471) (0/2/13472) (0/3/13473) (0/4/13474) 
(0/5/13475) (2/0/2245) (3/0/2245) 
2  Node id()=13235, processor_id()=4294967295, Point=(x,y,z)=(0.271875,   
0.2775,0)
DoFs=
3  Node id()=13233, processor_id()=4294967295, Point=(x,y,z)=(0.27,   
0.2775,0)
DoFs=
   n_sides()=4
neighbor(0)=nullptr
neighbor(1)=nullptr
neighbor(2)=nullptr
neighbor(3)=nullptr
   hmin()=9.89829e-11, hmax()=0.001875
   volume()=1.85593e-13
   active()=1, ancestor()=0, subactive()=0, has_children()=0
   parent()=672
   level()=4, p_level()=0
   refinement_flag()=DO_NOTHING
   p_refinement_flag()=DO_NOTHING
   DoFs=
Exiting...
[2] src/fe/fe_map.C, line 1905, compiled Apr 29 2019 at 13:59:12




> On May 1, 2019, at 9:29 PM, Stogner, Roy H  wrote:
> 
> 
> On Wed, 1 May 2019, Manav Bhatia wrote:
> 
>>  I am using h-refinement in my analysis, which uses the mesh function 
>> routines to compute the value of the function in the interior of an element.
>> 
>>  All of my elements in the original mesh (before any refinements) are 
>> squares (quad4).
>> 
>>  For the most part everything works out fine without any issues.
>>  Occasionally, however, I will get an error in the inverse_map()
>>  like this. I am particularly perplexed by the hmin() size of
>>  10^-11.
>> 
>>  The size of my elements before refinement is hmin() = .015 and I
>>  allow a max of 4 refinements in any element. Would there be any
>>  reason to expect an hmin of order 10^-11 in this case?
> 
> Not even close, but there's definitely *something* going seriously
> wrong here.
> 
> You have a degenerate element; points 0 and 3 and points 1 and 2
> coincide.
> 
> You have three nodes with invalid processor ids.
> 
> You probably ought to
> 
>> Rerun in devel/dbg mode for more details.
> 
> (preferably dbg) and see whether it catches any problems earlier.
> ---
> Roy


___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] problem with inverse_map()

[Manav Bhatia]

Any reason to expect such a sliver element when refining from squares? 

> On May 1, 2019, at 5:50 PM, John Peterson  wrote:
> 
> 
> On Wed, May 1, 2019 at 5:40 PM Manav Bhatia  <mailto:bhatiama...@gmail.com>> wrote:
> As a followup, I have attached a screenshot of where the element in the error 
> message is pointing. It is intriguing that the coordinates of all 4 nodes 
> have virtually the same y-axis location (hence the hmin of 10^-11). I have 
> circled the respective edge that these coordinates define. 
> 
> I should also note that I am using a custom function for flagging elements 
> for refinement/coarsening. I have a scalar function define on the elements, 
> and based on the value of the function I mark them for refinement or 
> coarsening. So, this is a simple less-then/greater-than block. Not sure I am 
> supposed to check for more parameters before flagging. 
> 
> All four nodes have basically the same y and z coordinates? Sounds like it is 
> a sliver element, so I'd say the hmin value is probably correct...
> 
> -- 
> John


___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] problem with inverse_map()

[Manav Bhatia]

As a followup, I have attached a screenshot of where the element in the error 
message is pointing. It is intriguing that the coordinates of all 4 nodes have 
virtually the same y-axis location (hence the hmin of 10^-11). I have circled 
the respective edge that these coordinates define. 

I should also note that I am using a custom function for flagging elements for 
refinement/coarsening. I have a scalar function define on the elements, and 
based on the value of the function I mark them for refinement or coarsening. 
So, this is a simple less-then/greater-than block. Not sure I am supposed to 
check for more parameters before flagging. 

Thanks,
Manav



> On May 1, 2019, at 5:25 PM, Manav Bhatia  wrote:
> 
> Hi, 
> 
>I am using h-refinement in my analysis, which uses the mesh function 
> routines to compute the value of the function in the interior of an element. 
> 
>All of my elements in the original mesh (before any refinements) are 
> squares (quad4). 
> 
>For the most part everything works out fine without any issues. 
> Occasionally, however, I will get an error in the inverse_map() like this. I 
> am particularly perplexed by the hmin() size of 10^-11. 
> 
>The size of my elements before refinement is hmin() = .015 and I allow a 
> max of 4 refinements in any element. Would there be any reason to expect an 
> hmin of order 10^-11 in this case? 
> 
> Thanks,
> Manav
> 
> 
> WARNING: At least one element took more than 10 iterations to converge in 
> inverse_map()...
> Rerun in devel/dbg mode for more details.
> ERROR: Newton scheme FAILED to converge in 21 iterations in element 16514 for 
> physical point = (x,y,z)=(0.27,   0.2775,0)
>   Elem Information
>id()=16514, processor_id()=2
>type()=QUAD4
>dim()=2
>n_nodes()=4
> 0  Node id()=13234, processor_id()=4294967295, Point=(x,y,z)=(0.27,   
> 0.2775,0)
> DoFs=
> 1  Node id()=604, processor_id()=2, Point=(x,y,z)=(0.271875,   0.2775,
> 0)
> DoFs=(0/0/13470) (0/1/13471) (0/2/13472) (0/3/13473) (0/4/13474) 
> (0/5/13475) (2/0/2245) (3/0/2245) 
> 2  Node id()=13235, processor_id()=4294967295, Point=(x,y,z)=(0.271875,   
> 0.2775,0)
> DoFs=
> 3  Node id()=13233, processor_id()=4294967295, Point=(x,y,z)=(0.27,   
> 0.2775,0)
> DoFs=
>n_sides()=4
> neighbor(0)=nullptr
> neighbor(1)=nullptr
> neighbor(2)=nullptr
> neighbor(3)=nullptr
>hmin()=9.89829e-11, hmax()=0.001875
>volume()=1.85593e-13
>active()=1, ancestor()=0, subactive()=0, has_children()=0
>parent()=672
>level()=4, p_level()=0
>refinement_flag()=DO_NOTHING
>p_refinement_flag()=DO_NOTHING
>DoFs=
> Exiting...
> [2] src/fe/fe_map.C, line 1905, compiled Apr 20 2019 at 20:02:41
> 


___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

[Libmesh-users] problem with inverse_map()

[Manav Bhatia]

Hi, 

   I am using h-refinement in my analysis, which uses the mesh function 
routines to compute the value of the function in the interior of an element. 

   All of my elements in the original mesh (before any refinements) are squares 
(quad4). 

   For the most part everything works out fine without any issues. 
Occasionally, however, I will get an error in the inverse_map() like this. I am 
particularly perplexed by the hmin() size of 10^-11. 

   The size of my elements before refinement is hmin() = .015 and I allow a max 
of 4 refinements in any element. Would there be any reason to expect an hmin of 
order 10^-11 in this case? 

Thanks,
Manav


WARNING: At least one element took more than 10 iterations to converge in 
inverse_map()...
Rerun in devel/dbg mode for more details.
ERROR: Newton scheme FAILED to converge in 21 iterations in element 16514 for 
physical point = (x,y,z)=(0.27,   0.2775,0)
  Elem Information
   id()=16514, processor_id()=2
   type()=QUAD4
   dim()=2
   n_nodes()=4
0  Node id()=13234, processor_id()=4294967295, Point=(x,y,z)=(0.27,   
0.2775,0)
DoFs=
1  Node id()=604, processor_id()=2, Point=(x,y,z)=(0.271875,   0.2775,  
  0)
DoFs=(0/0/13470) (0/1/13471) (0/2/13472) (0/3/13473) (0/4/13474) 
(0/5/13475) (2/0/2245) (3/0/2245) 
2  Node id()=13235, processor_id()=4294967295, Point=(x,y,z)=(0.271875,   
0.2775,0)
DoFs=
3  Node id()=13233, processor_id()=4294967295, Point=(x,y,z)=(0.27,   
0.2775,0)
DoFs=
   n_sides()=4
neighbor(0)=nullptr
neighbor(1)=nullptr
neighbor(2)=nullptr
neighbor(3)=nullptr
   hmin()=9.89829e-11, hmax()=0.001875
   volume()=1.85593e-13
   active()=1, ancestor()=0, subactive()=0, has_children()=0
   parent()=672
   level()=4, p_level()=0
   refinement_flag()=DO_NOTHING
   p_refinement_flag()=DO_NOTHING
   DoFs=
Exiting...
[2] src/fe/fe_map.C, line 1905, compiled Apr 20 2019 at 20:02:41


___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

[Libmesh-users] PostDoc positions

[Manav Bhatia]

Dear colleagues,

   I would greatly appreciate if you could forward this message to any 
interested audience. 

   My research group currently has multiple openings for Post-Doc positions 
with immediate availability. The broad scope of work includes: 

— topology optimization of geometrically nonlinear thermoelastic structures 
with conjugate heat transfer including flow modeling and internal radiation.
— large-scale fluid-structure interaction with focus on high-frequency acoustic 
response.

   The nature of work will involve mathematical modeling, development of 
solvers for large-scale systems and demonstration of solver on various 
applications of interest. 

   A successful candidate would have a strong foundation in finite element 
analysis along with experience in programming of solvers in C/C++. Experience 
with open-source tools such as PETSc, deal.II, libMesh, or similar libraries 
will be viewed favorably. 

   Interested people are encouraged to respond to mb2...@msstate.edu 
<mailto:mb2...@msstate.edu> with a CV.  

Regards,
Manav

Manav Bhatia, PhD
Assistant Professor
Department of Aerospace Engineering 
Center for Advanced Vehicular Systems
Graduate Coordinator, Computational Engineering
Mississippi State University
voice: 662-325-7202 
fax: 662-325-7730 
email: bha...@ae.msstate.edu <mailto:bha...@ae.msstate.edu>
http://bhatia.ae.msstate.edu <http://bhatia.ae.msstate.edu/>

--
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
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

[Libmesh-users] time varying Dirichlet Conditions

[Manav Bhatia]

Hi, 

   I am trying to identify the best approach to handle time-varying Dirichlet 
conditions with libMesh. It appears that DirichletConstraints is used to create 
a set of DofConstraintRow that is used after the nonlinear solves through 
DofMap::enforce_constraints_exactly(). 

   So, if time-varying DirichletConstraints are required, then the dof 
constraints will have to be reinitialized at each time-step with the 
DirichletCondition object returning the function values for that time? 

Is there another way to do this without have to reinit the constraints? 
Presently I am not using AMR. Would reinit of constraints at each time-step be 
the best approach if AMR is used?

Thanks,
Manav
--
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
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

[Libmesh-users] PostDoc position at MSU

[Manav Bhatia]

The Computational Dynamics and Design Lab (http://bhatia.ae.msstate.edu) at 
Mississippi State University has an immediate opening for a post-doctoral 
researcher. The work involves development of advanced finite element schemes 
for analysis and design of structures with plasticity and high strain-rate 
mechanics. Finite element analysis will involve high-order discretization with 
the development of adjoint-based error-metrics to drive hp-adaptivity for 
large-scale systems, and efficient adjoint-sensitivity analysis techniques for 
application in design optimization.

Applications are sought from highly motivated researchers with a PhD in 
Engineering/Physics/Applied Mathematics with strong mathematical and 
programming skills. A successful applicant will have:
— Prior programming experience for finite element analysis, preferably with 
MPI-enabled parallel computing.
— Proficiency with C/C++ programing.
— Exposure to open-source libraries for scientific computations, such as 
libMesh, Deal.II, PETSc, SLEPc, etc.
— Strong writing skills and experience with LaTeX. 

Interested candidates can email the following items to Prof. Manav Bhatia 
(bha...@ae.msstate.edu):
— CV including the contact information of references,
— representative publications.

Thanks,
Manav

--
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
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

[Libmesh-users] Question about constraining dofs

[Manav Bhatia]

Hi, 

I am using DofMap::add_constrain_row() to constrain some dofs to zero: 

   libMesh::DofConstraintRow c_row;
dof_map.add_constraint_row(*dof_it, c_row, true);

This is implemented in an object derived from System::Constrain. Then, I 
call System::reinit_constraints() before assembly. 

This has been working fine, but I have one case that is tripping the 
following error when I call SparseMatrix::add_matrix(). I am going to start to 
dig into this to figure out why this might be happening, but if there are any 
quick words of advice, that would be very helpful. 

I am a bit puzzled since this is for a diagonal entry. My understanding is 
that constraining dofs should not remove them from the sparsity pattern. I 
guess I am missing something here. 

Regards,
Manav   


[1;31m[0]PETSC ERROR: - Error Message 
--
[0;39m[0;49m[0]PETSC ERROR: Argument out of range
[0]PETSC ERROR: New nonzero at (7308,7308) caused a malloc
Use MatSetOption(A, MAT_NEW_NONZERO_ALLOCATION_ERR, PETSC_FALSE) to turn off 
this check
[0]PETSC ERROR: See http://www.mcs.anl.gov/petsc/documentation/faq.html for 
trouble shooting.
[0]PETSC ERROR: Petsc Release Version 3.8.0, unknown 
[0]PETSC ERROR: 
/Users/manav/Library/Developer/Xcode/DerivedData/mast_workspace-hfyswujevmwgyugsmyueuaouvmkj/Build/Products/Debug/example_driver
 on a arch-darwin-c-opt named Dhcp-90-164.HPC.MsState.Edu by manav Thu Mar  1 
10:42:54 2018
[0]PETSC ERROR: Configure options 
--prefix=/Users/manav/Documents/codes/numerical_lib/petsc/petsc/../ 
--CC=mpicc-openmpi-clang40 --CXX=mpicxx-openmpi-clang40 
--FC=mpif90-openmpi-clang40 --with-fortran=0 
--with-mpiexec=/opt/local/bin/mpiexec-openmpi-clang40 --with-shared-libraries=1 
--with-x=1 --with-x-dir=/opt/X11 --with-debugging=0 
--with-lapack-lib=/usr/lib/liblapack.dylib 
--with-blas-lib=/usr/lib/libblas.dylib --download-superlu=yes 
--download-superlu_dist=yes --download-suitesparse=yes --download-mumps=yes 
--download-scalapack=yes --download-parmetis=yes --download-metis=yes 
--download-hypre=yes --download-ml=yes
[0]PETSC ERROR: #1 MatSetValues_SeqAIJ() line 481 in 
/Users/manav/Documents/codes/numerical_lib/petsc/petsc/src/mat/impls/aij/seq/aij.c
[0]PETSC ERROR: #2 MatSetValues() line 1270 in 
/Users/manav/Documents/codes/numerical_lib/petsc/petsc/src/mat/interface/matrix.c




--
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
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] 1D/2D elements in 3D space

[Manav Bhatia]

Thanks! 

So, would the shape function derivatives account the orientation of the 
element? 

For instance, a 1D element oriented along:   x-axis   vs   y-axis   vs   x=y 
line. 

In all cases, there is only one shape function defined along the element 
coordinate. But its derivative wrt x and y will vary. Is this handled for both 
1st order and 2nd order Lagrange (for instance)?

-Manav

> On Feb 12, 2018, at 5:06 PM, Roy Stogner <royst...@ices.utexas.edu> wrote:
> 
> 
> On Mon, 12 Feb 2018, Manav Bhatia wrote:
> 
>>  I was looking through some code in FE and noticed some comments
>>  about 1D/2D elements in 3D space. What is the extent of support
>>  for this?
> 
> IIRC:
> 
> If you're using just one or just the other, then the support should be
> complete.
> 
> If you're connecting one to the other (or connecting either/both to 3D
> elements), then you don't get neighbor links for those connections.
> 
> If you're overlapping one on or within the other (e.g. elements which
> occupy the sides of higher dimensional elements) and you want them to
> share DoFs consistently then I think you're limited to LAGRANGE
> variables for those DoFs.
> ---
> 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
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

[Libmesh-users] 1D/2D elements in 3D space

[Manav Bhatia]

Hi, 

   I was looking through some code in FE and noticed some comments about 1D/2D 
elements in 3D space. What is the extent of support for this? 

   I have specialized code that handles this for 1D/2D elements in my 
application. But, if this is well supported in libMesh I can modify my code to 
leverage this capability. 

-Manav


--
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
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] ImplicitSystem::get_linear_solver()

[Manav Bhatia]

I added an member to my class by the name “linear_solver” and initialize it in 
the init_data() method using this snippet: 

linear_solver.reset(new libMesh::PetscLinearSolver(this->comm()));
if (libMesh::on_command_line("--solver_system_names")) {

std::string nm = this->name() + "_";
linear_solver->init(nm.c_str());
}


Seems to be working fine so far. 

-Manav


> On Jan 29, 2018, at 3:12 PM, Roy Stogner <royst...@ices.utexas.edu> wrote:
> 
> 
> On Mon, 29 Jan 2018, Manav Bhatia wrote:
> 
>> I ended up creating a function similar to the one in LInearImplicitSystem to 
>> get around this issue.
>> 
>> Working out fine now.
> 
> Good to hear.
> 
> Is your get_linear_solver() anything general enough to move upstream
> to NonlinearImplicitSystem?  The lack of a get_linear_solver()
> overload there might be because I was going to add one and realized
> some good reason why I couldn't, but a more likely scenario is just
> that I wasn't using (or testing with, therefore) that class and didn't
> want to implement something blind.
> ---
> 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
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] ImplicitSystem::get_linear_solver()

[Manav Bhatia]

I ended up creating a function similar to the one in LInearImplicitSystem to 
get around this issue. 

Working out fine now. 

Thanks!
Manav


> On Jan 29, 2018, at 1:59 PM, John Peterson <jwpeter...@gmail.com> wrote:
> 
> 
> 
> On Mon, Jan 29, 2018 at 11:42 AM, Manav Bhatia <bhatiama...@gmail.com 
> <mailto:bhatiama...@gmail.com>> wrote:
> Except for a sensitivity solve. 
> 
> Hmm... so you are referring to the get_linear_solver() calls in 
> 
> ImplicitSystem::adjoint_solve()
> ImplicitSystem::sensitivity_solve() 
> ImplicitSystem::weighted_sensitivity_adjoint_solve()
> ImplicitSystem::weighted_sensitivity_solve()
> 
> ?
> 
> If I understand correctly, those should all be calling the derived class 
> LinearImplicitSystem::get_linear_solver() method in practice.
> 
> In the class you are writing that is derived from NonlinearImplicitSystem, if 
> you hang on to your own LinearSolver object, you could write a function 
> similar to the one above to provide access to it.
> 
> -- 
> 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
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] ImplicitSystem::get_linear_solver()

[Manav Bhatia]

Except for a sensitivity solve. 

> On Jan 29, 2018, at 12:41 PM, John Peterson <jwpeter...@gmail.com> wrote:
> 
> 
> 
> On Mon, Jan 29, 2018 at 11:09 AM, Manav Bhatia <bhatiama...@gmail.com 
> <mailto:bhatiama...@gmail.com>> wrote:
> I see. 
> 
> So, I am defining a class that inherits from nonlinear_implicit_system, and 
> calling  get_linear_solver() on that.  This gets to the implementation in 
> implicit_system, since the nonlinear_implicit_system does not define an 
> overriding function. 
> 
> Instead, there is one defined in  linear_implicit_system, but that is a 
> different code path. 
> 
> 
> Right, the NonlinearImplicitSystem has a public nonlinear_solver member, but 
> it doesn't really make sense to call get_linear_solver() on a 
> NonlinearImplicitSystem, since it doesn't really have one to hand back.
> 
> -- 
> 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
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] ImplicitSystem::get_linear_solver()

[Manav Bhatia]

I see. 

So, I am defining a class that inherits from nonlinear_implicit_system, and 
calling  get_linear_solver() on that.  This gets to the implementation in 
implicit_system, since the nonlinear_implicit_system does not define an 
overriding function. 

Instead, there is one defined in  linear_implicit_system, but that is a 
different code path. 

-Manav


> On Jan 29, 2018, at 11:12 AM, John Peterson <jwpeter...@gmail.com> wrote:
> 
> 
> 
> On Mon, Jan 29, 2018 at 9:59 AM, Manav Bhatia <bhatiama...@gmail.com 
> <mailto:bhatiama...@gmail.com>> wrote:
> Hi,
> 
>  The source code says that the following method is deprecated:
> 
>  ImplicitSystem::get_linear_solver()
> 
>  This is, however, extensively being used in implicit_system.C.
> 
>   Is there a different method that I should be looking to use?
> 
> 
> Hmm... "deprecated" is a bit of a misnomer here, I think what will eventually 
> happen is that the base class implementation will be changed into a 
> libmesh_error() to prevent it from being accidentally called.
> 
> The usage you are referring to in implicit_system.C therefore represents 
> calls to derived class implementations, and should remain as-is.
> 
> If you are currently seeing a deprecation message from calling this function, 
> you are probably doing something wrong and need to fix your code, but I doubt 
> that's the case?
> 
> -- 
> 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
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

[Libmesh-users] ImplicitSystem::get_linear_solver()

[Manav Bhatia]

Hi, 

 The source code says that the following method is deprecated:

 ImplicitSystem::get_linear_solver()

 This is, however, extensively being used in implicit_system.C. 

  Is there a different method that I should be looking to use? 

Thanks,
Manav

--
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
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] Read/write solution vectors

[Manav Bhatia]

Aha!  Thanks for sharing this information. 

Are there any restrictions placed on the mesh type for this? 
Structured/Unstructured? 

What about distribution of dofs? Like subdomain variables, etc.

-Manav

> On Nov 7, 2017, at 12:11 PM, Paul T. Bauman <ptbau...@gmail.com> wrote:
> 
> On Tue, Nov 7, 2017 at 12:55 PM, Manav Bhatia <bhatiama...@gmail.com 
> <mailto:bhatiama...@gmail.com>> wrote:
> 
> This is unrelated:  is there any activity concerning multigrid 
> preconditioners within libMesh? I can certainly use Algebraic MG from PETSC, 
> but what about geometric MG?
> 
> Yes, we have a project going on this. We're debugging the pre-alpha version 
> and will be migrating into libMesh and generalizing (beyond H1 conforming 
> elements) hopefully very soon. We will make a formal announcement on the 
> lists once it's more "beta" to help shake out the interface for the users. It 
> is being hooked into PETSc's DM infrastructure, so PETSc will be required.

--
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
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] Read/write solution vectors

[Manav Bhatia]

Thanks! 

I did not know about the meshplot utility. I will consider migrating to XDR. 

This is unrelated:  is there any activity concerning multigrid preconditioners 
within libMesh? I can certainly use Algebraic MG from PETSC, but what about 
geometric MG? 

-Manav


> On Nov 7, 2017, at 11:52 AM, Roy Stogner <royst...@ices.utexas.edu> wrote:
> 
> 
> On Tue, 7 Nov 2017, Manav Bhatia wrote:
> 
>> What is the guidance on using element vs nodal solution functions?
>> 
>> Most of my computations use C0 Lagrange basis. These would be nodal?
> 
> Right.
> 
>> I sometimes also use high order Szabab. Would these also be nodal?
> 
> IIRC, yes.  I'm pretty sure they won't be restartable from an Exodus
> save file, though.
> 
>> Would any L2 function space be elemental?
> 
> Well, any H1 function space is also in L2.  But the discontinuous
> function spaces are all elemental.  I'm not sure you can get more than
> piecewise constants out to Exodus and back in again safely, though.
> ---
> 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
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] Read/write solution vectors

[Manav Bhatia]

Thanks! 

I see that this is all done using XDR. Is there a particular reason to prefer 
XDR as opposed to .exo? I understand that libMesh provides extensive API for 
this. 

Can XDR be used for data visualization? 

Do you know if someone has implemented a read function from .exo files? Given 
that I am already using it for post processing (visualization in Paraview), it 
would be good to use the same data for other computations, as opposed to 
writing XDR files in addition. 

-Manav

> On Nov 6, 2017, at 9:36 AM, David Knezevic  wrote:
> 
> Regarding this:
>  
> I seem to remember the Reduced Basis code doing something tricky...
> looks like it's using System::read_serialized_data() directly?
> 
> Yes, that's right. See RBEvaluation::read_in_vectors and 
> RBEvaluation::write_out_vectors.
> 
> David

--
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
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

[Libmesh-users] Read/write solution vectors

[Manav Bhatia]

Hi, 

   I have been writing my transient data to exodusII files and using them in 
Paraview for visualization using  ExodusII_IO::write_time_step()

   Is there a utility available to read previously written solution (to 
exodusII file) into memory into a System vector?

   If not, is there one available for a different format? Maybe XDR? 

   What are the limitations placed by adaptivity on either, given that the mesh 
topology can also be changing with time? 

Thanks,
Manav


--
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
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

[Libmesh-users] PostDoctoral Positions available at Mississippi State University

[Manav Bhatia]

The Computational Dynamics and Design Lab (CDDL) at Mississippi State 
University is currently looking to hire for one or more Post-Doctoral 
positions. The projects will involve the development and implementation of 
advanced finite element schemes for nonlinear fluid and/or structural systems. 
Phenomena of interest include turbulent and free-surface flows within the 
context of fluid dynamics, and large deformation structural response with 
material nonlinearity and high strain-rate mechanics. Finite element analysis 
will involve the use of high-order discretization with the development of 
adjoint-based error-metrics to drive hp-adaptivity for large-scale systems.

 

Opportunities also exist to collaborate with other ongoing activities at CDDL, 
including the development of cut-cell (immersed/unfitted) finite element 
methods for topology optimization of nonlinear thermoelastic structures and the 
study of nonlinear dynamics (bifurcation, limit-cycle-oscillations and chaos) 
arising from fluid-structure interactions.

 

The projects are expected to begin in Aug/Sept 2017. Applications for these 
positions are sought from highly motivated researchers with a PhD in 
Engineering/Physics/Applied Mathematics with strong mathematical and 
programming skills. Preference will be given to US Citizens and Permanent 
Residents. Candidates with the following skills and experience will be 
considered favorably:

·  Prior experience with advanced finite element analysis

·  Proficiency with C/C++ programing

·  Exposure to HPC software, preferably libMesh, PETSc and SLEPc.

·  Strong writing skills and experience with LaTex

 

Interested candidates can email the following items as a single PDF to Prof. 
Manav Bhatia (bha...@ae.msstate.edu) <mailto:bha...@ae.msstate.edu)>:

·  a cover letter,

·  a statement of research interests,

·  a CV including the contact information of three references,

·  representative publications
--
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
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] deleting DofConstraintRow

[Manav Bhatia]

Thanks for your detailed response, Roy. 

What method would provide the functionality to clear and reinitialize the dof 
constraints? 

I see that _dof_constraints.clear() is called in 
DofMap::create_dof_constraints(). But I wouldn’t call this directly (?). 

Regards,
Manav

> On Jul 7, 2017, at 11:31 AM, Roy Stogner <royst...@ices.utexas.edu> wrote:
> 
> 
> On Fri, 7 Jul 2017, Manav Bhatia wrote:
> 
>> I am working on a case where I need to dynamically add/remove constraints on 
>> dofs.
>> 
>> I see the method DofMap::add_constraint_row to add a constraint
>> row. Is there a corresponding method to delete these constraints
>> for the dofmap?
> 
> Not a good one, IIRC, and I'm sure you'd have seen it if there was one
> I'm forgetting.  I think all you could do at the moment is clear
> everything then re-add the constraints you want to retain, which
> sounds like an awful idea, until you read about the alternatives
> below...
> 
> We'd be happy to add a patch which adds this functionality (assuming
> it comes with a lot of unit testing so we don't break it again out
> from under you!), but I'm afraid that at the moment it's probably much
> harder than you're imagining to get it right in the general case:
> 
> For efficiency's sake, we currently pre-expand constraints.  So e.g.
> if DoF A depends on B and C, and C depends on D and E, and E depends
> on F and G, after (re-)initialization time the final constraint row
> will have A depending on B, D, F, and G.  If you were to then remove
> the constraint on C, the constraint on A would now be incorrect, and
> what's worse, there would be no easy way to tell it was incorrect,
> because in the expanded version there is no remaining A->C connection!
> 
> It would be reasonable to (optionally) forgo this pre-expansion, but
> a bit of other code would have to be added to handle the unexpanded
> case.  Dependency constraint equations would have to be communicated
> properly on DistributedMesh while leaving the dependent constraints
> unmodified, the send_list construction would have to be able to handle
> indirect dependencies, and enforce_constraints_exactly() would have to
> either walk through dependency trees or iterate up to the maximum tree
> depth, just off the top of my head.
> 
> Alternatively, we could keep two constraints data structures, one
> pre-expanded and one unexpanded, and use the latter to regenerate
> (just the relevant parts of) the former whenever a constraint is
> removed.  I'm not sure whether this would be easier or harder than the
> first option.
> ---
> 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
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

[Libmesh-users] deleting DofConstraintRow

[Manav Bhatia]

Hi, 

  I am working on a case where I need to dynamically add/remove constraints on 
dofs. 

  I see the method DofMap::add_constraint_row to add a constraint row. Is there 
a corresponding method to delete these constraints for the dofmap? 


Regards,
Manav  


--
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
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] reimplementing a virtual method

[Manav Bhatia]

Never mind..  I found the issue. I had a dynamic_cast in the code that was 
forcing this. 

Thanks anyways,
Manav

> On Feb 21, 2017, at 3:48 PM, Manav Bhatia <bhatiama...@gmail.com> wrote:
> 
> Hi, 
> 
>   This is a basic question, that I am bit embarrassed that I have to ask… 
> 
>   I am attempting to inherit from NonlinearImplictSystem and reimplement the 
> ImplicitSystem::assemble_residual_derivatives in the derived class. 
> 
>   I have the method declared like this in my derived class:
> 
> virtual void
> assemble_residual_derivatives
> (const libMesh::ParameterVector & parameters) override;
> 
>   Which is the same as that declared in ImplicitSystem, except the “override" 
> keyword, which appears as “libmesh_override” in ImplicitSystem. 
> 
>   I compile my code and run it, but the code path is still going through 
> ImplictSystem::assemble_residual_derivatives. 
> 
>   I have tried to make sure that I am turning on std=c++11 in my compile 
> options, but to no avail. 
> 
>   There is obviously something basic that I am missing. 
> 
>If something jumps out at the pros on this mailing list, I would greatly 
> appreciate their insight. 
> 
> Regards,
> Manav

--
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
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

[Libmesh-users] reimplementing a virtual method

[Manav Bhatia]

Hi, 

  This is a basic question, that I am bit embarrassed that I have to ask… 

  I am attempting to inherit from NonlinearImplictSystem and reimplement the 
ImplicitSystem::assemble_residual_derivatives in the derived class. 

  I have the method declared like this in my derived class:

virtual void
assemble_residual_derivatives
(const libMesh::ParameterVector & parameters) override;

  Which is the same as that declared in ImplicitSystem, except the “override" 
keyword, which appears as “libmesh_override” in ImplicitSystem. 

  I compile my code and run it, but the code path is still going through 
ImplictSystem::assemble_residual_derivatives. 

  I have tried to make sure that I am turning on std=c++11 in my compile 
options, but to no avail. 

  There is obviously something basic that I am missing. 

   If something jumps out at the pros on this mailing list, I would greatly 
appreciate their insight. 

Regards,
Manav
--
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
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] dynamically add/remove dofs

[Manav Bhatia]

If I create multiple elements that occupy the same (exact) spatial domain, but 
with distinct nodes (multiple nodes defined at the same spatial point), would 
there be any negative implication for ReplicatedMesh or ParallelMesh data 
structures? 

This is in relation to the implementation of XFEM where sometimes duplicate 
entities are defined for multiple levels of enrichment functions. 

Thanks,
Manav



> On Jan 27, 2017, at 10:26 AM, Roy Stogner <royst...@ices.utexas.edu> wrote:
> 
> 
> On Fri, 27 Jan 2017, Manav Bhatia wrote:
> 
>> The subdomain approach sounds promising.  I will look into this and
>> the SCALAR variable.
> 
> SCALAR you want to avoid for locally supported variables in fully
> implicit solves.  We generate dense rows and columns for each SCALAR
> dof, which is not what you want for efficiency when you know a priori
> that nearly all that coupling isn't really there.
> 
>> Another question:  the application in mind is topology optimization
>> with XFEM, where voids can form/disappear in a continuum during the
>> course of optimization. I don’t want to modify the mesh during this
>> procedure. So, if a certain portion of the domain becomes a void,
>> what would be the best approach to make the dofs inactive in that
>> void?
>> 
>> Can I simply iterate on the node/elem dofs and flag them as
>> active/inactive so that I don’t have to worry about
>> solving/specifying Dirichlet conditions for them?
> 
> I'd add a user constraint equation for each dof.
> ---
> 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
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] dynamically add/remove dofs

[Manav Bhatia]

Thanks for the clarification, John. 

Do you know if there have been XFEM implementations using libMesh in your group 
or elsewhere in the research community? 

Regards,
Manav


> On Jan 27, 2017, at 9:54 AM, John Peterson <jwpeter...@gmail.com> wrote:
> 
> 
> 
> On Fri, Jan 27, 2017 at 8:34 AM, Manav Bhatia <bhatiama...@gmail.com 
> <mailto:bhatiama...@gmail.com>> wrote:
> Hi,
> 
>I am curious if libMesh allows frequent addition/deletion of dofs to a 
> system.
> 
>What I have in mind is a two-phase fluid problem with some interface 
> boundary that is evolving with time. Then, if I choose to use XFEM or 
> Lagrange multipliers at the interface, then the nodes/elements where these 
> extra dofs will be defined will change with time.
> 
>How easy/difficult would it be to do this with libMesh?
> 
> Addition/deletion of dofs happens all the time during adaptive 
> refinement/coarsening, so in principle I think this should be possible.
> 
> One thing that isn't really possible is adding/removing _variables_ to a 
> system once it has been initialized, so e.g. representing the Lagrange 
> multipliers as SCALAR variables and changing the number of said variables 
> frequently would not work well. 
> 
> -- 
> 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
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

[Libmesh-users] fe szabab

[Manav Bhatia]

Hi, 

https://github.com/libMesh/libmesh/blob/master/src/fe/fe_szabab_shape_2D.C#L776 

  : It should also list TRI3.

Similarly, 

https://github.com/libMesh/libmesh/blob/master/src/fe/fe_szabab_shape_2D.C#L814 

  should also list QUAD4. 

-Manav
--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] question about distributed mesh

[Manav Bhatia]

Thanks for your comments, Derek. 

We have a few different machines here, all with about 2GB per compute core. One 
of the machines has 12 cores per node, and another has 20 cores per node. 

Why do you say that run time will be saved with ReplicatedMesh? Is this due to 
the reduced MPI communication? I don’t see why other operations would be 
cheaper. 

-Manav

> On Aug 15, 2016, at 12:22 PM, Derek Gaston <fried...@gmail.com> wrote:
> 
> A little late to the party - but we use all of the options you listed.  
> However: the one I would recommend is using ReplicatedMesh and just use less 
> cores per node in your cluster so that it fits.  It will save you an immense 
> amount of development time... and most likely a lot of run time as well.
> 
> How many cores do you have per node?  How much memory per node?
> 
> Derek
> 
> On Thu, Aug 11, 2016 at 5:04 PM Manav Bhatia <bhatiama...@gmail.com 
> <mailto:bhatiama...@gmail.com>> wrote:
> Cody, the 2GB was per core (not per node). Sorry for the poor choice of terms 
> earlier.
> 
> 
> 
> Maybe I should seek guidance along a different (but related) trajectory...
> 
> 
> How do folks on this mailing list handle FSI load/displacement mapping for 
> large mesh?
> 
> I have tried several options at my end, but each one seems to be run into a 
> challenge area:
> 
> — serial mesh for both fluid and structure:  eventually, runs into 
> insufficient memory for large models
> 
> — parallel mesh with carefully partitioned fluid/structured mesh so that 
> adjacent fluid/structural elems live on the same processors:  error-prone, 
> difficult to manage, inefficient
> 
> — parallel mesh with ghosted elements and augmented send list:  as explained 
> in the previous message, this did not do the trick.
> 
> In all of this, I have been depending on the MeshFunction class.
> 
> Should I try to move to DTK? If this what other folks use? Any other 
> recommendations?
> 
> Would greatly appreciate suggestions and guidance here.
> 
> Thanks,
> Manav
> 
> 
> 
> > On Aug 11, 2016, at 3:48 PM, Cody Permann <codyperm...@gmail.com 
> > <mailto:codyperm...@gmail.com>> wrote:
> >
> > No pointers (no pun intended) but how big is your mesh? Just curious.
> >
> > On Thu, Aug 11, 2016 at 2:47 PM Manav Bhatia <bhatiama...@gmail.com 
> > <mailto:bhatiama...@gmail.com> <mailto:bhatiama...@gmail.com 
> > <mailto:bhatiama...@gmail.com>>> wrote:
> > So, I did manage to get the combination of 
> > DistributedMesh::add_extra_ghost_elem() and DofMap::augment_send_list() to 
> > work, but it ended up not giving me the result I was hoping.
> >
> > Basically, my intent is to use MeshFunction to return solution values on a 
> > specified boundary, and I want this to work on all processors for a 
> > distributed mesh.
> >
> > I was hoping that if I make the elements at the specified boundary 
> > available (through ghost elements), along with their their dofs (through 
> > send list), the point locator would use this info to find the element 
> > containing a boundary point, and the mesh function would have access to the 
> > dofs for interpolation.
> >
> > However, the point locator does not seem to work with the ghost elements.
> >
> > Is there another way for me to get this desired result?
> >
> > I would appreciate any pointers.
> >
> > Thanks,
> > Manav
> >
> >
> >
> > > On Aug 11, 2016, at 10:16 AM, Roy Stogner <royst...@ices.utexas.edu 
> > > <mailto:royst...@ices.utexas.edu> <mailto:royst...@ices.utexas.edu 
> > > <mailto:royst...@ices.utexas.edu>>> wrote:
> > >
> > >
> > > On Thu, 11 Aug 2016, Manav Bhatia wrote:
> > >
> > >> So if I understand correctly, the current implementation of
> > >> DistributedMesh::add_extra_ghost_elem() only provides the G()
> > >> version of your new API
> > >
> > > Not even that.  It provides the G() version of the old API - you can
> > > flag current elements that should remain ghosted, when you're ready to
> > > delete remote elements you're responsible for having flagged the extra
> > > ghosted elements first, and IIRC you can't redistribute the mesh after
> > > it's been initally distributed.
> > >
> > >> without an “evaluable” entity? If my interest is in the E() entity,
> > >> would it be best to wait for your API, or is there a way to get it
> > >> to work in current libMesh?
> > >
> > > You can combine the ghost element flagging w

Re: [Libmesh-users] question about distributed mesh

[Manav Bhatia]

David, 

  The following if block seems to want a serial vector. I did try passing the 
System::current_local_solution to the mesh function, but it still resets the 
element to nullptr. 

-Manav

  // If we have an element, but it's not a local element, then we
  // either need to have a serialized vector or we need to find a
  // local element sharing the same point.
  if (element &&
  (element->processor_id() != this->processor_id()) &&
  _vector.type() != SERIAL)
{
  // look for a local element containing the point
  std::set point_neighbors;
  element->find_point_neighbors(p, point_neighbors);
  element = libmesh_nullptr;
  std::set::const_iterator   it  = 
point_neighbors.begin();
  const std::set::const_iterator end = point_neighbors.end();
  for (; it != end; ++it)
{
  const Elem * elem = *it;
  if (elem->processor_id() == this->processor_id())
{
  element = elem;
  break;
}
}
}



> On Aug 11, 2016, at 6:39 PM, David Knezevic <david.kneze...@akselos.com> 
> wrote:
> 
> On Thu, Aug 11, 2016 at 7:10 PM, Manav Bhatia <bhatiama...@gmail.com 
> <mailto:bhatiama...@gmail.com>> wrote:
> I got this to work!!!
> 
> The error was that I was not using a serialized vector to initialize the mesh 
> function. So, even though the point locator was finding the elem, the mesh 
> function was setting it to null due to the vector not being serial.
> 
> 
> FYI, it should be possible to get this to work with a GHOSTED vector. You 
> just have to augment the send_list correctly, and call the localize method 
> that takes the send_list argument.
> 

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] question about distributed mesh

[Manav Bhatia]

I got this to work!!! 

The error was that I was not using a serialized vector to initialize the mesh 
function. So, even though the point locator was finding the elem, the mesh 
function was setting it to null due to the vector not being serial.  

Now that this is working, I will try to get my other routines to work around 
the mesh function class. 

Still, if others could quickly poll in their preferred method for such multi 
physics computations (DTK, mesh function, etc.), that would give me a healthy 
perspective on this challenging problem. 

I am gradually moving towards wing/aerodynamicz type of FSI problems with 
non-matching boundary interfaces due to beam/plate representations of wing 
structural models and detailed OML representations for the fluid side. mesh 
function would not work there, since there is no overlap of geometry. I had 
brief discussions with DTK developers, and they have identified this as an area 
of interest, which is currently not supported. 

So, if someone on this list is already solving such problems, I am curious to 
learn about this solution transfer methodology. 

Any comments would help!

Thanks!
Manav


> On Aug 11, 2016, at 4:05 PM, Roy Stogner <royst...@ices.utexas.edu> wrote:
> 
> 
> On Thu, 11 Aug 2016, Manav Bhatia wrote:
> 
>> However, the point locator does not seem to work with the ghost elements.
> 
> This sounds like a bug, IMHO.  The point locator *ought* to find any
> ghost element accessible, whether it's retained by the library or by
> user request.
> 
> I can't guess what the bug might be, whether it's a user or a library
> bug, though.  You're requesting active elements when telling libMesh
> which to ghost, right?
> 
> Could you post a simple code that replicates the problem?
> ---
> Roy


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] question about distributed mesh

[Manav Bhatia]

This is without any refinement, so all elements should be active. Right? 

In order to find the elements for ghosting, I do the following: 

— create mesh with build_cube
— serialize mesh with MeshSerializer
— iterate over all elements and mark specific elements for ghosting
— call prepare_for_use on the mesh.
— augment send list 
— eq_sys init
— later in the code, I use the mesh function. 

I will create a small example and send it across. 

Thanks,
Manav


> On Aug 11, 2016, at 4:05 PM, Roy Stogner <royst...@ices.utexas.edu> wrote:
> 
> 
> On Thu, 11 Aug 2016, Manav Bhatia wrote:
> 
>> However, the point locator does not seem to work with the ghost elements.
> 
> This sounds like a bug, IMHO.  The point locator *ought* to find any
> ghost element accessible, whether it's retained by the library or by
> user request.
> 
> I can't guess what the bug might be, whether it's a user or a library
> bug, though.  You're requesting active elements when telling libMesh
> which to ghost, right?
> 
> Could you post a simple code that replicates the problem?
> ---
> Roy


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] question about distributed mesh

[Manav Bhatia]

About a million elements. 

I have tried serial mesh in the past, but that seems to be running into memory 
issues on our local HPC machines. We have about 2GB per node, not sure if that 
is enough. 

-Manav


> On Aug 11, 2016, at 3:48 PM, Cody Permann <codyperm...@gmail.com> wrote:
> 
> No pointers (no pun intended) but how big is your mesh? Just curious.
> 
> On Thu, Aug 11, 2016 at 2:47 PM Manav Bhatia <bhatiama...@gmail.com 
> <mailto:bhatiama...@gmail.com>> wrote:
> So, I did manage to get the combination of 
> DistributedMesh::add_extra_ghost_elem() and DofMap::augment_send_list() to 
> work, but it ended up not giving me the result I was hoping.
> 
> Basically, my intent is to use MeshFunction to return solution values on a 
> specified boundary, and I want this to work on all processors for a 
> distributed mesh.
> 
> I was hoping that if I make the elements at the specified boundary available 
> (through ghost elements), along with their their dofs (through send list), 
> the point locator would use this info to find the element containing a 
> boundary point, and the mesh function would have access to the dofs for 
> interpolation.
> 
> However, the point locator does not seem to work with the ghost elements.
> 
> Is there another way for me to get this desired result?
> 
> I would appreciate any pointers.
> 
> Thanks,
> Manav
> 
> 
> 
> > On Aug 11, 2016, at 10:16 AM, Roy Stogner <royst...@ices.utexas.edu 
> > <mailto:royst...@ices.utexas.edu>> wrote:
> >
> >
> > On Thu, 11 Aug 2016, Manav Bhatia wrote:
> >
> >> So if I understand correctly, the current implementation of
> >> DistributedMesh::add_extra_ghost_elem() only provides the G()
> >> version of your new API
> >
> > Not even that.  It provides the G() version of the old API - you can
> > flag current elements that should remain ghosted, when you're ready to
> > delete remote elements you're responsible for having flagged the extra
> > ghosted elements first, and IIRC you can't redistribute the mesh after
> > it's been initally distributed.
> >
> >> without an “evaluable” entity? If my interest is in the E() entity,
> >> would it be best to wait for your API, or is there a way to get it
> >> to work in current libMesh?
> >
> > You can combine the ghost element flagging with calls to
> > DofMap::augment_send_list() to make sure all dofs on the ghost
> > elements remain distributed.  The new API ought to make that much
> > easier though.
> >
> >> Perhaps follow the implementation in MOOSE?
> >
> > That's a good idea.  We've also got 2 augment_send_list() uses in the
> > libMesh examples, IIRC.
> > ---
> > Roy
> 
> 
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. http://sdm.link/zohodev2dev <http://sdm.link/zohodev2dev>
> ___
> Libmesh-users mailing list
> Libmesh-users@lists.sourceforge.net 
> <mailto:Libmesh-users@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/libmesh-users 
> <https://lists.sourceforge.net/lists/listinfo/libmesh-users>

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] question about distributed mesh

[Manav Bhatia]

Ok.  I am trying to do this to a mesh create with build_cube, which calls the 
prepare_for_use method before returning. 

I was going to attempt to use MeshSerializer to serialize the mesh, mark the 
necessary elements for ghosting, then augment_send_list.

Would this be acceptable? Or do the elements need to be marked for ghost in 
before prepare_for_use? 

Sent from my iPhone

> On Aug 11, 2016, at 10:16 AM, Roy Stogner  wrote:
> 
> Not even that.  It provides the G() version of the old API - you can
> flag current elements that should remain ghosted, when you're ready to
> delete remote elements you're responsible for having flagged the extra
> ghosted elements first, and IIRC you can't redistribute the mesh after
> it's been initally distributed.

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] question about distributed mesh

[Manav Bhatia]

will do. Thanks!

-Manav


> On Aug 10, 2016, at 5:43 PM, John Peterson <jwpeter...@gmail.com> wrote:
> 
> 
> 
> On Wed, Aug 10, 2016 at 4:40 PM, Manav Bhatia <bhatiama...@gmail.com 
> <mailto:bhatiama...@gmail.com>> wrote:
> Seems like DistributedMesh::add_extra_ghost_elem()  does the trick.
> 
> Roy is also in the midst of generalizing the algorithms used to control which 
> elements are ghosted where, so you may want to keep an eye on what he's 
> doing...
> 
> -- 
> John

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] question about distributed mesh

[Manav Bhatia]

Seems like DistributedMesh::add_extra_ghost_elem()  does the trick. 

-Manav

> On Aug 10, 2016, at 5:17 PM, Manav Bhatia <bhatiama...@gmail.com> wrote:
> 
> Hi, 
> 
>   Is it possible to tell/force DistributedMesh to maintain a copy of a 
> selected set of elements across all processors? 
> 
>   If this is currently is not a part of the functionality, is there a quick 
> and dirty way of accomplishing the same? 
> 
>   I would greatly appreciate your comments.
> 
> Thanks,
> Manav


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

[Libmesh-users] question about distributed mesh

[Manav Bhatia]

Hi, 

   Is it possible to tell/force DistributedMesh to maintain a copy of a 
selected set of elements across all processors? 

   If this is currently is not a part of the functionality, is there a quick 
and dirty way of accomplishing the same? 

   I would greatly appreciate your comments.

Thanks,
Manav
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] aclocal error

[Manav Bhatia]

I cloned the git master, and following a bootstrap that threw the error, the 
make seems to be moving along. 

Not sure what is going on, but happy to have this move forward. 

Thanks,
Manav

> On Jun 30, 2016, at 1:08 PM, John Peterson <jwpeter...@gmail.com> wrote:
> 
> 
> 
> On Thu, Jun 30, 2016 at 11:45 AM, Manav Bhatia <bhatiama...@gmail.com 
> <mailto:bhatiama...@gmail.com>> wrote:
> Hi,
> 
>I have been using libmesh on a local cluster for a couple of years now. 
> After upgrading to the latest version on github, configure runs fine, but 
> make is giving me the following error:
> 
> -bash-3.1$ make
> CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh 
> /cavs/projects/sams/codes/raptor/libmesh/libmesh/build-aux/missing 
> aclocal-1.15 -I m4
> /cavs/projects/sams/codes/raptor/libmesh/libmesh/build-aux/missing: line 81: 
> aclocal-1.15: command not found
> WARNING: 'aclocal-1.15' is missing on your system.
>  You should only need it if you modified 'acinclude.m4' or
>  'configure.ac <http://configure.ac/>' or m4 files included by 
> 'configure.ac <http://configure.ac/>'.
>  The 'aclocal' program is part of the GNU Automake package:
>  <http://www.gnu.org/software/automake 
> <http://www.gnu.org/software/automake>>
>  It also requires GNU Autoconf, GNU m4 and Perl in order to run:
>  <http://www.gnu.org/software/autoconf 
> <http://www.gnu.org/software/autoconf>>
>  <http://www.gnu.org/software/m4/ <http://www.gnu.org/software/m4/>>
>  <http://www.perl.org/ <http://www.perl.org/>>
> make: *** [aclocal.m4] Error 127
> 
> Running bootstrap gives the following error:
> 
> -bash-3.1$ ./bootstrap
> Autoconf Version 2.59 too old, building a new one...
> Indaequate Libtool (ltmain.sh (GNU libtool) 1.5.22 (1.1220.2.365 2005/12/18 
> 22:14:06)), building a new one...
> Automake Version 1.9 too old, building a new one...
> Inadequate autotools in your path, I'll build new ones...
>   building autoconf-2.69 in 
> /cavs/projects/sams/codes/raptor/libmesh/libmesh/contrib/autotools
> configure: error: no acceptable m4 could be found in $PATH.
> GNU M4 1.4.6 or later is required; 1.4.16 or newer is recommended.
> GNU M4 1.4.15 uses a buggy replacement strstr on some systems.
> Glibc 2.9 - 2.12 and GNU M4 1.4.11 - 1.4.15 have another strstr bug.
>   building automake-1.15 in 
> /cavs/projects/sams/codes/raptor/libmesh/libmesh/contrib/autotools
> configure: error: Autoconf 2.65 or better is required.
>   building libtool-2.4.6 in 
> /cavs/projects/sams/codes/raptor/libmesh/libmesh/contrib/autotools
> configure: error: no acceptable m4 could be found in $PATH.
> GNU M4 1.4.6 or later is required; 1.4.16 or newer is recommended.
> GNU M4 1.4.15 uses a buggy replacement strstr on some systems.
> Glibc 2.9 - 2.12 and GNU M4 1.4.11 - 1.4.15 have another strstr bug.
> autoreconf: Entering directory `.'
> autoreconf: configure.ac <http://configure.ac/>: not using Gettext
> autoreconf: running: aclocal --force -I m4
> aclocal:configure.ac:72 <http://configure.ac:72/>: warning: macro 
> `AM_SILENT_RULES' not found in library
> configure.ac:8 <http://configure.ac:8/>: error: Autoconf version 2.69 or 
> higher is required
> configure.ac:8 <http://configure.ac:8/>: the top level
> autom4te: /usr/bin/m4 failed with exit status: 63
> aclocal: autom4te failed with exit status: 63
> autoreconf: aclocal failed with exit status: 63
> 
> 
> Short of building the latest autotools on this machine, is there something I 
> can do to the source to still use the system installed autotools?
> 
> Would greatly appreciate advice on this.
> 
> We fixed this a while ago... by latest version do you mean 1.0.0 or git 
> master branch?
> 
> If you run ./bootstrap once, it should fix the problem.
> 
> -- 
> John

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

[Libmesh-users] aclocal error

[Manav Bhatia]

Hi, 

   I have been using libmesh on a local cluster for a couple of years now. 
After upgrading to the latest version on github, configure runs fine, but make 
is giving me the following error:

-bash-3.1$ make
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh 
/cavs/projects/sams/codes/raptor/libmesh/libmesh/build-aux/missing aclocal-1.15 
-I m4
/cavs/projects/sams/codes/raptor/libmesh/libmesh/build-aux/missing: line 81: 
aclocal-1.15: command not found
WARNING: 'aclocal-1.15' is missing on your system.
 You should only need it if you modified 'acinclude.m4' or
 'configure.ac' or m4 files included by 'configure.ac'.
 The 'aclocal' program is part of the GNU Automake package:
 
 It also requires GNU Autoconf, GNU m4 and Perl in order to run:
 
 
 
make: *** [aclocal.m4] Error 127

Running bootstrap gives the following error: 

-bash-3.1$ ./bootstrap 
Autoconf Version 2.59 too old, building a new one...
Indaequate Libtool (ltmain.sh (GNU libtool) 1.5.22 (1.1220.2.365 2005/12/18 
22:14:06)), building a new one...
Automake Version 1.9 too old, building a new one...
Inadequate autotools in your path, I'll build new ones...
  building autoconf-2.69 in 
/cavs/projects/sams/codes/raptor/libmesh/libmesh/contrib/autotools
configure: error: no acceptable m4 could be found in $PATH.
GNU M4 1.4.6 or later is required; 1.4.16 or newer is recommended.
GNU M4 1.4.15 uses a buggy replacement strstr on some systems.
Glibc 2.9 - 2.12 and GNU M4 1.4.11 - 1.4.15 have another strstr bug.
  building automake-1.15 in 
/cavs/projects/sams/codes/raptor/libmesh/libmesh/contrib/autotools
configure: error: Autoconf 2.65 or better is required.
  building libtool-2.4.6 in 
/cavs/projects/sams/codes/raptor/libmesh/libmesh/contrib/autotools
configure: error: no acceptable m4 could be found in $PATH.
GNU M4 1.4.6 or later is required; 1.4.16 or newer is recommended.
GNU M4 1.4.15 uses a buggy replacement strstr on some systems.
Glibc 2.9 - 2.12 and GNU M4 1.4.11 - 1.4.15 have another strstr bug.
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
aclocal:configure.ac:72: warning: macro `AM_SILENT_RULES' not found in library
configure.ac:8: error: Autoconf version 2.69 or higher is required
configure.ac:8: the top level
autom4te: /usr/bin/m4 failed with exit status: 63
aclocal: autom4te failed with exit status: 63
autoreconf: aclocal failed with exit status: 63


Short of building the latest autotools on this machine, is there something I 
can do to the source to still use the system installed autotools? 

Would greatly appreciate advice on this. 

Regards,
Manav

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] mpi split: possible bug

[Manav Bhatia]

Looks good to me, Roy. 

While we are at it, I have one more observation: 

Consider the global comm with ranks {0, 1, 2, 3}. 

Then, after the following intended split: {0}, which requires rank {0} to 
request split with a color and ranks {1, 2, 3} with MPI_UNDEFINED, the 
mpi_communicator on the latter set will have a value MPI_COMM_NULL. 

The method Communicator::assign(), compares the value of the new comm against 
MPI_COMM_NULL. If a valid comm is found, then the rank and size are set 
consistently, otherwise they are set to 0 and 1. So, in the above simple case, 
a call to comm.rank() and comm.size() on all cpus for the new subcomm will 
always return 0 and 1.

Of course, the use can explicitly check comm.get() == MPI_COMM_NULL to see if a 
communicator is valid or not. But, I am not sure if this is intended. In any 
case, I wanted to point this out. 


Thanks,
Manav




> On Mar 11, 2016, at 8:24 AM, Roy Stogner <royst...@ices.utexas.edu> wrote:
> 
> 
> On Fri, 11 Mar 2016, Manav Bhatia wrote:
> 
>> From the current status of the code in parallel.h, it looks like
>> mpi_comm_free is called only when _I_duped_it is true, which is
>> true only when Communicator::duplicate() is called.
>> 
>> I think the communicator created using split() also needs to be
>> destroyed using comm_free. But since _I_duped_it is not set to true
>> with split(), it does not seem like comm_free would be called when
>> the communicator goes out of scope.
>> 
>> I would appreciate if someone could confirm this.
> 
> This appears to be correct.  In my defense, some of the MPI
> documentation examples don't free the results of an MPI_Comm_split
> either.  In the offense, others of the MPI examples do free the
> MPI_Comm_split output, and I probably should have read through more
> than one example before writing the code.
> 
> I'll put in a PR to fix it now.
> 
> Thanks,
> ---
> Roy


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

[Libmesh-users] mpi split: possible bug

[Manav Bhatia]

Hi, 

  From the current status of the code in parallel.h, it looks like 
mpi_comm_free is called only when _I_duped_it is true, which is true only when 
Communicator::duplicate() is called. 

  I think the communicator created using split() also needs to be destroyed 
using comm_free. But since _I_duped_it is not set to true with split(), it does 
not seem like comm_free would be called when the communicator goes out of scope.

  I would appreciate if someone could confirm this. 

Thanks,
Manav


  
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

[Libmesh-users] split MPI communicators

[Manav Bhatia]

Hi, 

  I have two system of equations (fluid and structure) that are solved on two 
different mesh and that communicate with each other through a boundary. 

  If I want to perform the two solutions on two disjoint subset of processors, 
then would it make sense to:

—  create a LibMeshInit object with the global comm  ->   split it on 
the two subset of processors   -> use these subset to initialize the mesh

or

—  split it on the two subset of processors -> create a LibMeshInit 
object with each split comm  ->  use these comm from each LibMeshInit 
to initialize the mesh


   Any guidance will be appreciated. 

Thanks,
Manav



--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] unique id error

[Manav Bhatia]

Hi, 

   Please find the attached code and output when run with mpiexec -np 2 
./a.out. 

   The attached files are: 

config_options:  the list of options used to build libmesh
mesh.cpp:  the code used to reproduce the error
err_output   :  the output when run with mpiexec -np 2 ./a.out

Please let me know if you need more information. 

Thanks,
Manav


> On Mar 1, 2016, at 5:33 PM, Roy Stogner <royst...@ices.utexas.edu> wrote:
> 
> 
> On Tue, 1 Mar 2016, Manav Bhatia wrote:
> 
>> I have libMesh compiled with --enable-unique-id. 
>> For a sample problem, I am using the following command to build a 
>> ParallelMesh 
>>   libMesh::MeshTools::Generation::build_square(*_mesh,
>>10, 10,
>>0, _length,
>>0, _width,
>>e_type);
>> 
>>  When I run in debug mode I get the following error.
> 
> Could you send me a copy of code (and instructions e.g. how many
> processors to run on) reproducing the error?
> 
>> — how critical is unique-id support for parallel mesh?
> 
> If your mesh's entities all have unique hilbert ids (i.e. there's no
> overlapping nodes or element centroids) then the unique_id is
> unnecessary.
> 
>> — Is there a correct way to initialize a parallel mesh using
>> MeshTools that would not trip this error?
> 
> No, you're almost certainly doing things right.  I'd very much
> appreciate if you could help reproduce the problem so I can find the
> bug.
> ---
> Roy

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

[Libmesh-users] unique id error

[Manav Bhatia]

Hi, 

  I have libMesh compiled with --enable-unique-id. 

  For a sample problem, I am using the following command to build a 
ParallelMesh 

libMesh::MeshTools::Generation::build_square(*_mesh,
 10, 10,
 0, _length,
 0, _width,
 e_type);

   When I run in debug mode I get the following error.  When I run in opt mode, 
everything works out fine, so the error is not doing anything to mess up my 
computations. 

A few questions: 

— how critical is unique-id support for parallel mesh? 
— Is there a correct way to initialize a parallel mesh using MeshTools that 
would not trip this error? 

I would appreciate any insight. 

Thanks,
Manav



Assertion `this->comm().semiverify(obj ?  : nullptr)' failed.

[1] src/mesh/parallel_mesh.C, line 904, compiled Feb 25 2016 at 23:15:16

 
--
| Processor id:   1 
   |
| Num Processors: 2 
   |
| Time:   Tue Mar  1 17:08:35 2016  
   |
| OS: Darwin
   |
| HostName:   Dhcp-90-199.HPC.MsState.Edu   
   |
| OS Release: 15.3.0
   |
| OS Version: Darwin Kernel Version 15.3.0: Thu Dec 10 18:40:58 PST 2015; 
root:xnu-3248.30.4~1/RELEASE_X86_64  |
| Machine:x86_64
   |
| Username:   manav 
   |
| Configuration:  ./configure  
'--prefix=/Users/manav/Documents/codes/libmesh/libmesh/../' 
|
|  '--enable-mpi'   
   |
|  '--enable-unique-id' 
   |
|  '--enable-dependency-tracking'   
   |
|  '--enable-fortran'   
   |
|  '--enable-shared'
   |
|  '--enable-exceptions'
   |
|  '--disable-openmp'   
   |
|  '--disable-default-comm-world'   
   |
|  '--enable-tracefiles'
   |
|  '--enable-amr'   
   |
|  '--enable-vsmoother' 
   |
|  '--enable-periodic'  
   |
|  '--enable-dirichlet' 
   |
|  '--enable-parmesh'   
   |
|  '--enable-nodeconstraint'
   |
|  '--enable-ghosted'   
   |
|  '--enable-pfem'  
   |
|  '--enable-ifem'  
   |
|  '--enable-second'
   |
|  '--enable-xdr'   
   |
|  '--enable-reference-counting'
   |
|  '--enable-perflog'   
   |
|  '--enable-examples'  
   |
|  

Re: [Libmesh-users] compilation issue on mac

[Manav Bhatia]

This was a great hunch, John! 
I touched base with PETSC developers and was able to identify it to be an issue 
with the configuration parameter. 

-Manav

> On Feb 25, 2016, at 6:22 PM, John Peterson <jwpeter...@gmail.com> wrote:
> 
> 
> 
> On Thu, Feb 25, 2016 at 4:44 PM, Manav Bhatia <bhatiama...@gmail.com 
> <mailto:bhatiama...@gmail.com>> wrote:
> I am not sure if I have been able to find it in my directory. 
> 
> Attached is the output of make V=1. 
> 
> Just judging from where the offending libraries are situated in the link line:
> 
> > /Users/manav/Documents/codes/numerical_lib/petsc/petsc-3.6.3/../lib/libsundials_nvecparallel.a
> >  -lmpi_cxx.dyl -lmpi.dyl -lsuperlu_4.3 -lsuperlu_dist_4.1 -llapack -lblas 
> > -lparmetis -lmetis -lX11 -lhwloc 
> 
> I'd say they are probably being requested by sundials, via PETSc.
> 
> Look in $PETSC_DIR/lib/petsc/conf/petscvariables and see if the .dyl things 
> are mentioned there.
> 
> -- 
> John

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

[Libmesh-users] compilation issue on mac

[Manav Bhatia]

Hi, 

   I am compiling libMesh from github/master on a mac 10.11 with openmpi from 
macports. I get the following error at the end when the build system is trying 
to build the executables. 


ld: library not found for -lmpi_cxx.dyl

 When I run with V=1 option, I notice that the build system is adding .dyl 
to the library name.  

 -lmpi_cxx.dyl -lmpi.dyl 

   Any help would be appreciated. 

Thanks,
Manav

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

[Libmesh-users] LinearSolver::init_names

[Manav Bhatia]

Hi, 

   I noticed that the init_names (to call pc_auto fieldsplit) is called in the 
NewtonSolver context, but not for PetscNonlinearSolver. 

   Is that something that can be added at an appropriate place in the 
initialization of the latter? Not sure if this needs to be done before calling 
KSPSetFromOptions, or after. 

Regards,
Manav



--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

[Libmesh-users] solving a complex system with real numbers

[Manav Bhatia]

Hi, 
 
   I am working on a problem that requires solution of a complex system of 
equations about a real steady-state solution. The variables remain the same in 
these cases, just that they are assumed real in latter, and complex in the 
former. The complex Newton update 

(J_R + i J_I) (x_R + i x_I) + (r_R + i r_I) = 0

is then defined as 

[ J_R   -J_I] {x_R}  +  {r_R}  = {0}
[ J_IJ_R] {x_I}  +  {r_I}  = {0}

   In the past I have done this with two systems: one with N variables for the 
real solution, and another with 2N variables (one for real part, one for 
imaginary part) for the complex solution. This way, libMesh handles all the 
sparsity/dofs for the complex problem. This has worked well for the most part. 

   Presently, I am evaluating a few different options, primarily with the 
intent to use only one system with N variables. 

— I tried to implement a block-Jacobi method on the real-system (with N 
variables). This shows poor performance for high frequency values where the 
Jacobian is no longer diagonally dominant. Maybe there are ways to improve the 
convergence in such a situation. In any case, this allows me to use a single 
system. 

— I am considering adding code to create another matrix of twice the size and 
feed it to the LinearSolver class for solution. This will also require writing 
code around this for the Newton updates. The advantage is that the linear 
solver will see a single matrix. 

— I noticed that there is a way to initialize the SparseMatrix using a block 
structure. Perhaps it would make sense to define a block size of 2 (for a real 
and imaginary parts of each dof) and use this matrix initialization procedure. 
I need to also dig a bit into Petsc’s manuals to understand this better. 

— Similarly, I could create the matrix and give it to the NonlinearSolver. 

Are there other strategies someone on this list could suggest? 

What caveats do you see in pursuing one of the last three directions? 


I would greatly appreciate some guidance on this. 

Thanks,
Manav


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

[Libmesh-users] lagrange multipliers

[Manav Bhatia]

Hi, 

   I am curious if anyone has any experience/thoughts about addition of 
Lagrange multipliers to handle multi body dynamic constraints. 

   This would likely need addition of Lagrange variables associated with 
individual constraint equations, as opposed to the example problem (in source 
code) which uses Lagrange multiplier with the incompressible N-S equations, 
requiring a distributed scalar variable. 

Any thoughts on how this could be included in the libMesh framework? 

Thanks,
Manav


--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] lagrange multipliers

[Manav Bhatia]

Thanks for your response, David. 

I guess I need to understand the definition of a scalar variable within the 
context of libMesh. If I do 

system.add_variable (alpha, FIRST, SCALAR);

then, how many dofs are created for alpha? and are they distributed across the 
mesh? 

If I have N primary dofs, u_i (i=1,…,N), in the system, and M equations of the 
form 

f_j (u_i) = 0  (j=1,…,M)

then I would need M Lagrange multipliers. How would I go about adding them? 
Would I have to do the following


for (unsigned int i=0; iM; i++)
   system.add_variable (name_of_i_th_multiplier, FIRST, SCALAR);


Thanks,
Manav


 On Apr 7, 2015, at 2:09 PM, David Knezevic david.kneze...@akselos.com wrote:
 
 On Tue, Apr 7, 2015 at 2:55 PM, Manav Bhatia bhatiama...@gmail.com 
 mailto:bhatiama...@gmail.com wrote:
 Hi,
 
I am curious if anyone has any experience/thoughts about addition of 
 Lagrange multipliers to handle multi body dynamic constraints.
 
This would likely need addition of Lagrange variables associated with 
 individual constraint equations, as opposed to the example problem (in source 
 code) which uses Lagrange multiplier with the incompressible N-S equations, 
 requiring a distributed scalar variable.
 
 Any thoughts on how this could be included in the libMesh framework?
 
 
 IIRC at the moment we assume that all dofs in the system can be involved in 
 the constraint equation (i.e. SCALAR variables are coupled with all other 
 dofs). That is the most general case, and as a result you should be able to 
 impose whatever constraint equation you want using a SCALAR Lagrange 
 mulitplier, no?
 
 We could be more efficient (i.e. allocate fewer dofs in the sparsity pattern) 
 if we knew that the constraint was local to a few dofs. But that's just an 
 optimization...
 
 Am I misinterpreting you here?
 
 David
 
 

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] parmetis troubles

[Manav Bhatia]

Is there a motivation to keep scalar as the real type in
parmetis_partitioner.h?

Why not change this to the real type in metis.h?

-Manav


On Fri, Mar 13, 2015 at 12:27 PM, Manav Bhatia bhatiama...@gmail.com
wrote:

 not a problem...
 enjoy your conference and have a safe trip!

 -Manav


 On Fri, Mar 13, 2015 at 12:24 PM, Paul T. Bauman ptbau...@gmail.com
 wrote:

 Thanks for the report. We'll get it sorted soon. I'm about to leave for
 SIAM CSE, as are other developers I anticipate so it may be a few days.

 On Fri, Mar 13, 2015 at 1:19 PM, Manav Bhatia bhatiama...@gmail.com
 wrote:

 Found it!!!

 So, I did specify PETSc as the source of metis during compilation of
 libmesh (as I have been doing successfully for a while on my mac). However,
 for some reason, the compile options included the libmesh/contrib/metis and
 libmesh/contrib/parmetis as search paths.

 As a result, the compiler was using metis.h from libmesh/contrib, but
 using libmetis.so and libparmetis.so library from petsc. The
 libmesh/contrib has a real width of 32, and uses float as scalar in
 parmetis_partitioner, while the petsc metis library was build with real
 width type of 64.

 I do not know why contrib stuff is still being used, but this mismatch
 was causing the error.

 On Fri, Mar 13, 2015 at 6:24 AM, Paul T. Bauman ptbau...@gmail.com
 wrote:

 On Fri, Mar 13, 2015 at 12:52 AM, Manav Bhatia bhatiama...@gmail.com
 wrote:

Parmetis is quitting on me with segmentation faults. The code works
 just fine on other machines (both mac and some big intel based clusters).
 Before I spend more time debugging it, I wanted to get a quick check from
 others if they have had issues if parmetis.


 Make sure you use the configure option --with-metis=PETSc

 The libMesh and PETSc ParMetis installations can (and often do) collide
 and that option will tell libMesh to use PETSc's.





--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] parmetis troubles

[Manav Bhatia]

Correction: I had meant to write real as the scalar type (instead of
scalar as the real type) in my previous message.

-Manav


On Fri, Mar 13, 2015 at 12:44 PM, Manav Bhatia bhatiama...@gmail.com
wrote:

 Is there a motivation to keep scalar as the real type in
 parmetis_partitioner.h?

 Why not change this to the real type in metis.h?

 -Manav


 On Fri, Mar 13, 2015 at 12:27 PM, Manav Bhatia bhatiama...@gmail.com
 wrote:

 not a problem...
 enjoy your conference and have a safe trip!

 -Manav


 On Fri, Mar 13, 2015 at 12:24 PM, Paul T. Bauman ptbau...@gmail.com
 wrote:

 Thanks for the report. We'll get it sorted soon. I'm about to leave for
 SIAM CSE, as are other developers I anticipate so it may be a few days.

 On Fri, Mar 13, 2015 at 1:19 PM, Manav Bhatia bhatiama...@gmail.com
 wrote:

 Found it!!!

 So, I did specify PETSc as the source of metis during compilation of
 libmesh (as I have been doing successfully for a while on my mac). However,
 for some reason, the compile options included the libmesh/contrib/metis and
 libmesh/contrib/parmetis as search paths.

 As a result, the compiler was using metis.h from libmesh/contrib, but
 using libmetis.so and libparmetis.so library from petsc. The
 libmesh/contrib has a real width of 32, and uses float as scalar in
 parmetis_partitioner, while the petsc metis library was build with real
 width type of 64.

 I do not know why contrib stuff is still being used, but this mismatch
 was causing the error.

 On Fri, Mar 13, 2015 at 6:24 AM, Paul T. Bauman ptbau...@gmail.com
 wrote:

 On Fri, Mar 13, 2015 at 12:52 AM, Manav Bhatia bhatiama...@gmail.com
 wrote:

Parmetis is quitting on me with segmentation faults. The code
 works just fine on other machines (both mac and some big intel based
 clusters). Before I spend more time debugging it, I wanted to get a quick
 check from others if they have had issues if parmetis.


 Make sure you use the configure option --with-metis=PETSc

 The libMesh and PETSc ParMetis installations can (and often do)
 collide and that option will tell libMesh to use PETSc's.






--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] parmetis troubles

[Manav Bhatia]

not a problem...
enjoy your conference and have a safe trip!

-Manav


On Fri, Mar 13, 2015 at 12:24 PM, Paul T. Bauman ptbau...@gmail.com wrote:

 Thanks for the report. We'll get it sorted soon. I'm about to leave for
 SIAM CSE, as are other developers I anticipate so it may be a few days.

 On Fri, Mar 13, 2015 at 1:19 PM, Manav Bhatia bhatiama...@gmail.com
 wrote:

 Found it!!!

 So, I did specify PETSc as the source of metis during compilation of
 libmesh (as I have been doing successfully for a while on my mac). However,
 for some reason, the compile options included the libmesh/contrib/metis and
 libmesh/contrib/parmetis as search paths.

 As a result, the compiler was using metis.h from libmesh/contrib, but
 using libmetis.so and libparmetis.so library from petsc. The
 libmesh/contrib has a real width of 32, and uses float as scalar in
 parmetis_partitioner, while the petsc metis library was build with real
 width type of 64.

 I do not know why contrib stuff is still being used, but this mismatch
 was causing the error.

 On Fri, Mar 13, 2015 at 6:24 AM, Paul T. Bauman ptbau...@gmail.com
 wrote:

 On Fri, Mar 13, 2015 at 12:52 AM, Manav Bhatia bhatiama...@gmail.com
 wrote:

Parmetis is quitting on me with segmentation faults. The code works
 just fine on other machines (both mac and some big intel based clusters).
 Before I spend more time debugging it, I wanted to get a quick check from
 others if they have had issues if parmetis.


 Make sure you use the configure option --with-metis=PETSc

 The libMesh and PETSc ParMetis installations can (and often do) collide
 and that option will tell libMesh to use PETSc's.




--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] parmetis troubles

[Manav Bhatia]

Thanks for the correction, John. I had meant to say float.

At my end, I have temporarily changed all floats to double in the
metis/parmetis files in libmesh, but this is a temporary fix.

It would be better to source it from the respective headers. But that
raises another point: as of now, it seems like the metis.h in contrib has a
hardcoded value of real width to be 32. I understand that this saves memory
space, but would there be a motivation to keep this scalar type to be
consistent with the rest of the library?

-Manav

On Fri, Mar 13, 2015 at 1:18 PM, John Peterson jwpeter...@gmail.com wrote:



 On Fri, Mar 13, 2015 at 11:54 AM, Manav Bhatia bhatiama...@gmail.com
 wrote:

 Correction: I had meant to write real as the scalar type (instead of
 scalar as the real type) in my previous message.


 Hmm... I don't see a single instance of Real in either metis_partitioner.h
 or parmetis_partitioner.h.  Perhaps you are referring to:

   std::vectorfloat  _tpwgts;
   std::vectorfloat  _ubvec;

 which use float?  I agree that should probably be changed, along with
 using Metis' idx_t for indexing instead of hard-coding int.

 --
 John

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] parmetis troubles

[Manav Bhatia]

Yes, I have been doing that. 

U am getting an error from Parmetis saying 

The sum of tpwgts for constraint #0 is not 1.0

I searched Parmetis' website and did not find anything conclusive to point me 
in a direction. There was someone who did a reinstall of mpi to get around 
this, but that is hardly a solution in my case. 

-Manav



 On Mar 13, 2015, at 6:24 AM, Paul T. Bauman ptbau...@gmail.com wrote:
 
 On Fri, Mar 13, 2015 at 12:52 AM, Manav Bhatia bhatiama...@gmail.com wrote:
Parmetis is quitting on me with segmentation faults. The code works just 
 fine on other machines (both mac and some big intel based clusters). Before 
 I spend more time debugging it, I wanted to get a quick check from others if 
 they have had issues if parmetis.
 
 Make sure you use the configure option --with-metis=PETSc
 
 The libMesh and PETSc ParMetis installations can (and often do) collide and 
 that option will tell libMesh to use PETSc's. 
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] remote_elem singleton setup

[Manav Bhatia]

I have compared this with how the code executes on my Mac (which works fine). 

So far, my understanding is that RemoteElemSetup needs to be called prior to 
getting into this setup routine. But for some reason it is not in this case.  
Would that be a compiler error? Can this be forced in the code somehow? 

-Manav



 On Mar 11, 2015, at 10:12 AM, Roy Stogner royst...@ices.utexas.edu wrote:
 
 
 On Wed, 11 Mar 2015, Manav Bhatia wrote:
 
 I am working on getting the stack trace. The problem is that if I
 comment the “lock” line out, then the code crashes with a
 segmentation-fault without a stack trace. There is, obviously,
 something that I am not doing right.
 
 No need to comment the lock line out.  Try just sticking a call to
 print_trace() before the line.
 
 Or if you want to get in there interactively: I know debugging in
 parallel is a pain, but if you can exhibit the problem on a handful of
 processors it can be done without expensive tools.  Even in the worst
 case (parallel, no make install yet) something like this should work:
 
 mpirun -np 2 xterm -e bash -c libtool --mode=execute gdb --args 
 ./my_prog-dbg --my_options
 
 I was alluding towards the call immediately after the setup, which reads
 libmesh_assert(remote_elem);
 Sorry I have not been too clear and specific. 
 
 Ah!  I get it now.  I was assuming you were failing an assertion in
 remote_elem.C.  Now I understand where you are, no need for a stack
 trace.
 
 This is definitely baffling!  It's probably worth it to get in the
 debugger, then, so you can set some break points.  See if
 Singleton::setup_cache includes the RemoteElemSetup object, for
 example.  If so, see if RemoteElemSetup::setup() gets called.  If not,
 see if the Singleton::Setup::Setup() constructor is getting called
 from the RemoteElemSetup::RemoteElemSetup() constructor.
 
 I am at the following commit: abb4c2ffde19788495882db392f61fde18d365d3
 
 That should be fine.
 
 Is there a gcc vs icc thing here, perhaps?
 
 I don't think so.  icc 11 is pretty old, but I used to use it
 extensively, and it didn't have any problems with static object
 constructors.
 
 It looks almost as if the TBB vs pthreads issue is a red herring too;
 if we have an initialization order problem then that might just
 trigger or not trigger depending on how objects happen to link on one
 configuration vs another.
 ---
 Roy


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

[Libmesh-users] parmetis troubles

[Manav Bhatia]

Hi, 

   I am now running my code linked to libMesh that uses parmetis from petsc 
version 3.5.3. The specific version of parmetis is 4.0.2. My compiler is gcc 
4.4.7 with openmpi-1.8.3.

   Parmetis is quitting on me with segmentation faults. The code works just 
fine on other machines (both mac and some big intel based clusters). Before I 
spend more time debugging it, I wanted to get a quick check from others if they 
have had issues if parmetis. 

Thanks,
Manav


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] remote_elem singleton setup

[Manav Bhatia]

 On Mar 12, 2015, at 10:57 AM, John Peterson jwpeter...@gmail.com wrote:
 
 
 
 On Thu, Mar 12, 2015 at 9:48 AM, Manav Bhatia bhatiama...@gmail.com 
 mailto:bhatiama...@gmail.com wrote:
 Got it to work.
 
 Changed the compiler to gcc-4.4 and things seems to be working fine.
 
 Good to know, but GCC 4.4 isn't much newer than Intel 11... I'd try to update 
 to something newer as soon as possible unless you don't administer this 
 machine.
 

I do not have any control over this machine. It would be nice to have a newer 
compiler, but for now, I am happy to get this to work after 4 days of 
troubleshooting.

My next step is to get this to build on another machine which has a native 
gcc4.1 compiler. I will see how that goes. (Fingers crossed).



 We may just have to flag Intel-11 as not working in the back of our minds, 
 at least as far as our static initialization needs are concerned...
  
 
 There may have been other things wrong with my earlier attempts: for example, 
 I was using an intel-11.1 compiler to compile on an AMD Opteron machine.
 
 That should work fine in principle.
 
 -- 
 John

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] remote_elem singleton setup

[Manav Bhatia]

 On Mar 12, 2015, at 11:06 AM, Kirk, Benjamin (JSC-EG311) 
 benjamin.k...@nasa.gov wrote:
 
 
 On Mar 12, 2015, at 11:01 AM, Manav Bhatia bhatiama...@gmail.com wrote:
 
 My next step is to get this to build on another machine which has a native 
 gcc4.1 compiler. I will see how that goes. (Fingers crossed).
 
 FWIW, I run a build compatibility test with libMesh vanilla code (no 
 dependencies) using gcc-3.4, so you should have at least a fighting chance!

That is good to know, Ben. Thanks! 

So far I have made it through building petsc and slepc using 4.1. Next is 
libmesh…. will keep you posted. 

-Manav


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] remote_elem singleton setup

[Manav Bhatia]

Got it to work. 

Changed the compiler to gcc-4.4 and things seems to be working fine. 

There may have been other things wrong with my earlier attempts: for example, I 
was using an intel-11.1 compiler to compile on an AMD Opteron machine. 

In any case, I can now more forward with some runs. 

Thanks for your help. 

-Manav


 On Mar 11, 2015, at 11:43 AM, Roy Stogner royst...@ices.utexas.edu wrote:
 
 
 On Wed, 11 Mar 2015, Manav Bhatia wrote:
 
 I double checked, and I am using a C++ compiler to link. 
 
 Moreover, I ran make check in the examples director, and came across the 
 same problem. 
 
 If you want to drop the issue now that you've got a workaround, nobody
 will blame you.
 
 If you're curious to investigate further, though...
 
 
 #include iostream
 
 struct TestGlobal
 {
TestGlobal() { std::cout  TestGlobal()  std::endl; }
 };
 
 TestGlobal test_global;
 
 int main(void)
 {
std::cout  main()  std::endl;
return 0;
 }
 
 
 Does that properly construct the global first?  What if you move
 test_global into a separate file and link it in?
 ---
 Roy


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] remote_elem singleton setup

[Manav Bhatia]

 On Mar 11, 2015, at 8:11 AM, Roy Stogner royst...@ices.utexas.edu wrote:
 
 
 On Wed, 11 Mar 2015, Manav Bhatia wrote:
 
  I seem to be facing the same issue as described here: 
 http://sourceforge.net/p/libmesh/mailman/message/31297017/ 
 http://sourceforge.net/p/libmesh/mailman/message/31297017/
 
  If I build with pthreads and tbb, the code hangs at the singleton::setup 
 call.
 
 Do you mean Singleton::Setup::Setup() (as in the above issue, which
 was fixed)?  Or Singleton::setup()?  Either way, could you post a
 stack trace?

I meant the call through line libmesh.C:(370) to Singleton::setup(); 

I am working on getting the stack trace. The problem is that if I comment the 
“lock” line out, then the code crashes with a segmentation-fault without a 
stack trace. There is, obviously, something that I am not doing right.

 
 Without pthreads, it seems to be crashing at the following assert for 
 remote_elem.
 
 I didn't see an assert in your email.  We'll need to see the stack
 trace, too; most of the asserts in RemoteElem are of the form this
 function shouldn't ever be called and aren't informative unless you
 know which code is making the call.


I was alluding towards the call immediately after the setup, which reads

libmesh_assert(remote_elem);

Sorry I have not been too clear and specific. 

 
  I noticed that the earlier discussion had some talk about a patch
  to comment out the scoped_lock calls. Is that still applicable?
 
 Well, if we commented out *all* the scoped_lock calls then we'd be
 running into race condition errors left and right.  I removed just the
 one scoped_lock call that appeared to be extraneous and appeared to be
 using an uninitialized mutex.
 
  I am using intel 11.1 compiler with openmpi 1.4.2, if that is of relevance.
 
 It does rule out a couple possible problems, thanks.
 
 Which libMesh release (or git checkout hash) are you using?

I am at the following commit: abb4c2ffde19788495882db392f61fde18d365d3

Is there a gcc vs icc thing here, perhaps?

 
 What's your configure line?  Check your libmesh_config.h and make sure
 it's detecting TBB?  IIRC we don't internally *use* pthreads unless
 TBB isn't found.
 

It was able to find TBB. Here are the concerned lines 

/* Flag indicating whether the library shall be compiled to use the Threading
   Building Blocks */
#ifndef LIBMESH_HAVE_TBB_API
#define LIBMESH_HAVE_TBB_API 1
#endif

/* define if the compiler supports tbb::tbb_thread */
#ifndef LIBMESH_HAVE_TBB_CXX_THREAD
#define LIBMESH_HAVE_TBB_CXX_THREAD 1
#endif


Following is the configure options: 

/* Configuration information. */
#ifndef LIBMESH_CONFIGURE_INFO
#define LIBMESH_CONFIGURE_INFO ./configure  
'--prefix=/cavs/projects/sams/codes/raptor/libmesh/libmesh/../' '--enable-mpi' 
'--enable-unique-id' '--enable-dependency-tracking' '
--enable-fortran' '--enable-shared' '--enable-exceptions' '--disable-openmp' 
'--disable-default-comm-world' '--enable-tracefiles' '--enable-amr' 
'--enable-vsmoother' '--enable-p
eriodic' '--enable-dirichlet' '--enable-parmesh' '--enable-nodeconstraint' 
'--enable-ghosted' '--enable-pfem' '--enable-ifem' '--enable-second' 
'--enable-xdr' '--enable-referenc
e-counting' '--enable-perflog' '--enable-examples' '--enable-boost' 
'--disable-trilinos' '--enable-tbb' '--disable-pthreads' '--enable-sfc' 
'--disable-tecplot' '--disable-tecio'
 '--enable-metis' '--enable-parmetis' '--enable-tetgen' '--enable-triangle' 
'--enable-vtk' '--enable-hdf5' '--enable-libHilbert' '--enable-nanoflann' 
'--enable-exodus' '--enable
-netcdf' '--enable-petsc' '--enable-slepc' 
'--with-mpi=/usr/local/mpi-intel/x86_64/openmpi-1.5.5/' '--with-metis=PETSc' 
'--with-hdf5=/usr/local/hdf5-1.8.11/' '--with-vtk-lib=/us
r/local/vtk/x86_64/lib/vtk-5.4/' 
'--with-vtk-include=/usr/local/vtk/x86_64/include/vtk-5.4/' 
'--with-tbb=/usr/local/intel-11.1/tbb' 
'--with-tbb-lib=/usr/local/intel-11.1/tbb/lib
/intel64' '--with-methods=opt dbg' 'CXX=mpicxx' 
'CXXFLAGS=-I/cavs/projects/sams/codes/raptor/libmesh/libmesh/../../petsc/include
 -I/usr/local/vtk/x86_64/include/vtk-5.4/' 'LIBS=
-L/usr/local/intel-11.1/tbb/lib/intel64 
-L/usr/local/mpi-intel/x86_64/openmpi-1.4.2/lib -lmpi_cxx -lmpi' 'CC=mpicc' 
'CFLAGS=-I/cavs/projects/sams/codes/raptor/libmesh/libmesh/..
/../petsc/include' 'FC=mpif90' 'F77=mpif90' 
'PETSC_DIR=/cavs/projects/sams/codes/raptor/libmesh/libmesh/../../petsc' 
'SLEPC_DIR=/cavs/projects/sams/codes/raptor/libmesh/libmesh/
../../slepc'
#endif



 Thanks,
 ---
 Roy

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Libmesh-users

Re: [Libmesh-users] remote_elem singleton setup

[Manav Bhatia]

 On Mar 11, 2015, at 11:43 AM, Roy Stogner royst...@ices.utexas.edu wrote:
 
 
 On Wed, 11 Mar 2015, Manav Bhatia wrote:
 
 I double checked, and I am using a C++ compiler to link. 
 
 Moreover, I ran make check in the examples director, and came across the 
 same problem. 
 
 If you want to drop the issue now that you've got a workaround, nobody
 will blame you.
 

I am sorry, no workaround yet. I apparently misspoke. Still trying to get this 
to work. Trying to see if using a more recent compiler would do the trick. 

 If you're curious to investigate further, though...
 
 
 #include iostream
 
 struct TestGlobal
 {
TestGlobal() { std::cout  TestGlobal()  std::endl; }
 };
 
 TestGlobal test_global;
 
 int main(void)
 {
std::cout  main()  std::endl;
return 0;
 }
 
 
 Does that properly construct the global first?  What if you move
 test_global into a separate file and link it in?
 ---
 Roy


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] remote_elem singleton setup

[Manav Bhatia]

 On Mar 11, 2015, at 10:52 AM, Roy Stogner royst...@ices.utexas.edu wrote:
 
 
 On Wed, 11 Mar 2015, Manav Bhatia wrote:
 
 I have compared this with how the code executes on my Mac (which works fine).
 
 So far, my understanding is that RemoteElemSetup needs to be called
 prior to getting into this setup routine. But for some reason it is
 not in this case.  Would that be a compiler error?
 
 Did you make a global LibMeshInit variable?  If so, then the solution
 is don't do that!”
 

no no.. I don’t do global libMeshInit. It occurs inside the body of main() 
function. 

 If not, then this actually *could* be a compiler error.  There's a
 RemoteElemSetup object, remote_elem_setup (verify that in the
 debugger), and it's a global object, so it's constructor is supposed
 to be called before main().
 

It is not getting called. I put a breakpoint there (actually, in the 
constructor of Singleton::Setup::Setup()) and the code does not get to it. 

 Can this be forced in the code somehow?
 
 As a workaround you could call RemoteElem::create() manually before
 that assertion.
Will try this now. 

-Manav
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] remote_elem singleton setup

[Manav Bhatia]

I added the line 

RemoteElem::create(); 

in between the calls to Singleton::setup() and libmesh_assert(remote_elem); 

Now the code is crashing in 
libMesh::ReferenceCounter::increment_constructor_count(). 

It seems like there may be another static initialization that reference counter 
depends on. If so, then this could point towards a compiler issue. 

-Manav



 On Mar 11, 2015, at 10:52 AM, Roy Stogner royst...@ices.utexas.edu wrote:
 
 
 On Wed, 11 Mar 2015, Manav Bhatia wrote:
 
 I have compared this with how the code executes on my Mac (which works fine).
 
 So far, my understanding is that RemoteElemSetup needs to be called
 prior to getting into this setup routine. But for some reason it is
 not in this case.  Would that be a compiler error?
 
 Did you make a global LibMeshInit variable?  If so, then the solution
 is don't do that!
 
 If not, then this actually *could* be a compiler error.  There's a
 RemoteElemSetup object, remote_elem_setup (verify that in the
 debugger), and it's a global object, so it's constructor is supposed
 to be called before main().
 
 Can this be forced in the code somehow?
 
 As a workaround you could call RemoteElem::create() manually before
 that assertion.
 ---
 Roy


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] remote_elem singleton setup

[Manav Bhatia]

I double checked, and I am using a C++ compiler to link. 

Moreover, I ran make check in the examples director, and came across the same 
problem. 

-Manav


 On Mar 11, 2015, at 11:35 AM, John Peterson jwpeter...@gmail.com wrote:
 
 
 
 On Wed, Mar 11, 2015 at 10:10 AM, Roy Stogner royst...@ices.utexas.edu 
 mailto:royst...@ices.utexas.edu wrote:
 
 On Wed, 11 Mar 2015, Manav Bhatia wrote:
 
  It is not getting called. I put a breakpoint there (actually, in the
  constructor of Singleton::Setup::Setup()) and the code does not get
  to it.
 
 This is looking more and more like a compiler bug, then.  You must be
 linking in remote_elem.C or you'd be missing the remote_elem symbol;
 but if you're linking in remote_elem.C then you should be getting
 the...
 
 Wait a minute.  Is it possible you're using something other than icpc
 for the final link step?  IIRC you need to do the linking with a C++
 compiler for it to get the global constructors right.
 
 This is a good point.  Your application Makefile should use 
 
 $(LIBMESH_DIR)/contrib/bin/libtool --tag=CXX --mode=link (...args...)
 $(LIBMESH_DIR)/contrib/bin/libtool --tag=CXX --mode=install (...args...)
 
 for creating end-user shared libraries and executables.  Here are some 
 example make targets used by MOOSE.  I haven't included all the variables but 
 hopefully you get the idea...
 
 $(app_LIB):
   @$(libmesh_LIBTOOL) --tag=CXX $(LIBTOOLFLAGS) --mode=link --quiet 
 $(libmesh_CXX) $(libmesh_CXXFLAGS) -o $@ $(curr_objs) $(libmesh_LDFLAGS) 
 $(EXTERNAL_FLAGS) -rpath $(curr_dir)/lib $(curr_libs)
   @$(libmesh_LIBTOOL) --mode=install --quiet install -c $@ $(curr_dir)/lib
 
 $(app_EXEC):
   @$(libmesh_LIBTOOL) --tag=CXX $(LIBTOOLFLAGS) --mode=link --quiet 
 $(libmesh_CXX) $(libmesh_CXXFLAGS) -o $@ $(main_object) $(app_LIBS) 
 $(libmesh_LIBS) $(libmesh_LDFLAGS) $(EXTERNAL_FLAGS) $(ADDITIONAL_LIBS)
 
 
 -- 
 John

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] remote_elem singleton setup

[Manav Bhatia]

Ok. So I am in the debugger and stepping through the code. 

The size of setup_cache in Singleton::setup() (line 84 of libMesh_singleton.C) 
is zero. So, the for loop is not doing anything. 

-Manav


 On Mar 11, 2015, at 10:12 AM, Roy Stogner royst...@ices.utexas.edu wrote:
 
 
 On Wed, 11 Mar 2015, Manav Bhatia wrote:
 
 I am working on getting the stack trace. The problem is that if I
 comment the “lock” line out, then the code crashes with a
 segmentation-fault without a stack trace. There is, obviously,
 something that I am not doing right.
 
 No need to comment the lock line out.  Try just sticking a call to
 print_trace() before the line.
 
 Or if you want to get in there interactively: I know debugging in
 parallel is a pain, but if you can exhibit the problem on a handful of
 processors it can be done without expensive tools.  Even in the worst
 case (parallel, no make install yet) something like this should work:
 
 mpirun -np 2 xterm -e bash -c libtool --mode=execute gdb --args 
 ./my_prog-dbg --my_options
 
 I was alluding towards the call immediately after the setup, which reads
 libmesh_assert(remote_elem);
 Sorry I have not been too clear and specific. 
 
 Ah!  I get it now.  I was assuming you were failing an assertion in
 remote_elem.C.  Now I understand where you are, no need for a stack
 trace.
 
 This is definitely baffling!  It's probably worth it to get in the
 debugger, then, so you can set some break points.  See if
 Singleton::setup_cache includes the RemoteElemSetup object, for
 example.  If so, see if RemoteElemSetup::setup() gets called.  If not,
 see if the Singleton::Setup::Setup() constructor is getting called
 from the RemoteElemSetup::RemoteElemSetup() constructor.
 
 I am at the following commit: abb4c2ffde19788495882db392f61fde18d365d3
 
 That should be fine.
 
 Is there a gcc vs icc thing here, perhaps?
 
 I don't think so.  icc 11 is pretty old, but I used to use it
 extensively, and it didn't have any problems with static object
 constructors.
 
 It looks almost as if the TBB vs pthreads issue is a red herring too;
 if we have an initialization order problem then that might just
 trigger or not trigger depending on how objects happen to link on one
 configuration vs another.
 ---
 Roy


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

[Libmesh-users] remote_elem singleton setup

[Manav Bhatia]

Hi, 

   I seem to be facing the same issue as described here: 
http://sourceforge.net/p/libmesh/mailman/message/31297017/ 
http://sourceforge.net/p/libmesh/mailman/message/31297017/ 
  
   If I build with pthreads and tbb, the code hangs at the singleton::setup 
call. Without pthreads, it seems to be crashing at the following assert for 
remote_elem. 

   I noticed that the earlier discussion had some talk about a patch to comment 
out the scoped_lock calls. Is that still applicable? 

   I am using intel 11.1 compiler with openmpi 1.4.2, if that is of relevance. 

Thanks,
Manav

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] dof numbering

[Manav Bhatia]

I finally got a chance to get back to this problem. 

I played around with the different orderings available in petsc, 
-pc_factor_mat_ordering_type, and Quotient Minimum Degree seemed to do the 
trick. I am able to solve the system with about 7.5 GB of memory footprint in 
about 4.5 minutes, whereas all other ordering types throw out of memory errors. 

-Manav


 On Feb 6, 2015, at 10:41 PM, Jed Brown j...@jedbrown.org wrote:
 
 Manav Bhatia bhatiama...@gmail.com writes:
 
 Ok. Just so that I understand your point:  you are saying that because
 petsc (and other advanced direct solvers) will calculate a new
 ordering for the matrix factorization, it does not help to calculate
 it in advance. 
 
 Correct.  Though the PETSc native LU is probably the most basic solver
 you'll ever use.  The third party packages (-pc_type umfpack, mumps,
 superlu_dist, etc.) are much more advanced.
 
 However, for a more basic direct solver, which does not calculate the
 reordering as a part of its factorization, it may be beneficial to
 calculate this reordering in advance. correct?
 
 You'll probably never find such an implementation unless you write it
 yourself and either ignore the literature or intentionally stop halfway
 on the implementation.


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] DofConstraintRow

[Manav Bhatia]

Question about dof constraints and sparsity pattern: 

If the dofs constraint row is used to couple two dofs that otherwise do not 
have any coupling in the mesh (meaning, they belong to independent elements), 
then is this information taken into account in defining the sparsity pattern? 

Thanks,
Manav


 On Jan 20, 2015, at 2:47 PM, Roy Stogner royst...@ices.utexas.edu wrote:
 
 
 On Tue, 20 Jan 2015, Manav Bhatia wrote:
 
 Am  going to give the multipoint constraint a try.
 
 I am curious. Is this handled internally by simply replacing the equation 
 for the constrained dof with the specified row?
 
 The two options are replace the old equation and scream and die if
 there was already a constraint, yeah.  The latter is a nice check if
 you think you've found an algorithm that avoids conflicting with other
 constraints but you're not certain.
 ---
 Roy


--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] dof numbering

[Manav Bhatia]

Ok. Just so that I understand your point:  you are saying that because petsc 
(and other advanced direct solvers) will calculate a new ordering for the 
matrix factorization, it does not help to calculate it in advance. However, for 
a more basic direct solver, which does not calculate the reordering as a part 
of its factorization, it may be beneficial to calculate this reordering in 
advance. correct? 

-Manav

 On Feb 6, 2015, at 10:11 PM, Jed Brown j...@jedbrown.org wrote:
 
 
 One of those orderings is already being computed for your matrix as part
 of the analysis (or symbolic factorization) step.

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] dof numbering

[Manav Bhatia]

 On Feb 6, 2015, at 9:40 PM, Jed Brown j...@jedbrown.org wrote:
 
 Manav Bhatia bhatiama...@gmail.com writes:
 I am not sure if I understand your point. Are you saying that using a
 fill-reducing ordering for the dofs would not change the performance
 of a direct solver?
 
 Correct.  The solver is already computing an ordering (e.g., with nested
 dissection).  You can change the ordering algorithm as a run-time option
 to most solvers.  Natural ordering is an option with the PETSc
 solvers, but it's pretty much always super slow.
 
 Either ABAQUS is building a different matrix (e.g., different
 discretization) or using a different ordering algorithm, but there is no
 point reordering your dofs to help out.


Ok. Then how does the discussion about the fill-reduction using something like 
metis fit into this:

http://en.wikipedia.org/wiki/Sparse_matrix#Reducing_fill-in 
http://en.wikipedia.org/wiki/Sparse_matrix#Reducing_fill-in
http://matrixprogramming.com/2008/05/metis 
http://matrixprogramming.com/2008/05/metis

Does that not qualify as a reordering algorithm? Or are you talking about a 
matrix that is already available in dense format and the dof connectivity is 
not know? One could still deduce some connectivity information from the sparse 
matrix storage, and use that to run through METIS. Or not?

-Manav

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] dof numbering

[Manav Bhatia]

 On Feb 6, 2015, at 9:29 PM, Jed Brown j...@jedbrown.org wrote:
 
 Manav Bhatia bhatiama...@gmail.com writes:
 
 I am in agreement with that. However my situation is more rudimentary than 
 that. 
 
 If I run the same problem in ABAQUS, it uses a multifraontal direct solver 
 and gets done in two minutes. 
 
 If I use the -ksp_type preonly -pc_type lu on my code built on libmesh and 
 petsc, it takes ~16GB in storage and half hour for solution. 
 
 Do you have the same matrix in both cases?  Direct solvers compute an
 ordering (e.g., by nested dissection), so changing the ordering of your
 matrices is not likely to change much.  What direct solver is ABAQUS
 calling?

All that I could find in its manuals is that it uses a multifront technique 
(http://www.maths.cam.ac.uk/computing/software/abaqus_docs/docs/v6.12/books/usb/default.htm?startat=pt03ch06s01aus46.html#usb-anl-asolveroverview).
 

I am not sure if I understand your point. Are you saying that using a 
fill-reducing ordering for the dofs would not change the performance of a 
direct solver? 

-Manav


--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

[Libmesh-users] dof numbering

[Manav Bhatia]

Hi, 

   I am trying to understand the dof numbering a bit better. 

   The simulation I have at hand is that of a solid mechanics problem with 
thermal load. This has a total of ~770,000 dofs, and so far none of the 
iterative solves in petsc has provided good convergence property. Hence, I am 
stuck with using direct solvers. 

As a result, it is important for me to have a fill reducing dof numbering 
for my problems. Some of my dofs are coupled only through the dof constraints, 
not through a physical element connectivity. I have two different sets of such 
coupling constraints. One set is applied independently, and the second set is 
applied in addition to the first set. 

What I have observed is that the -ksp_type preonly -pc_type lu is able to 
solve with only the first set of dof constraints applied (but takes a lot of 
memory ~16 GB, which is all that my computer has). However, petsc complains 
about insufficient memory when I apply the second set in addition to the first. 

I suspect that renumbering the dofs using a fill-reducing criteria by 
accounting for these dof constraints could address the problem. However, I am 
not sure if the current code setup allows this to be done in libMesh. What I 
see is that the partitioners are associated with the MeshBase class, without 
any information from the DofMap. 

I would appreciate any insight in this matter. 

Thanks,
Manav


--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] dof numbering

[Manav Bhatia]

I tried the MUMPS option through petsc using this set of options: 

-ksp_type preonly -pc_type lu -pc_factor_mat_solver_package mumps 
-mat_mumps_icntl_ 22 1 -mat_mumps_icntl_ 23 1 

However, MUMPS does not seems to be running on my machine with the PETSC build. 
I build 3.5.3 today with the download mumps option, and it has not worked even 
for small problems. 

But you seem to be suggesting that MUMPS has a builtin fill-reduction 
algorithm. Correct? Also, do you have experience with the out-of-core option of 
MUMPS? 

Manav



 On Feb 6, 2015, at 8:47 PM, David Knezevic david.kneze...@akselos.com wrote:
 
 It sounds like you're right at the limit of what your computer can handle 
 with a direct solver. Which direct solver are you using? I generally use 
 MUMPS or SuperLU instead of PETSc's built in direct solver (e.g. -ksp_type 
 preonly -pc_type lu -pc_factor_mat_solver_package superlu_dist). I think 
 SuperLU typically uses less RAM than MUMPS, so maybe you should try that?
 
 Also, I know that with MUMPS you can try different fill-reduction algorithms, 
 which can be controlled via PETSc's ictnl flags 
 http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/MatMumpsSetIcntl.html.
 
 David
 
 
 
 
 On Sat, Feb 7, 2015 at 10:33 AM, Manav Bhatia bhatiama...@gmail.com 
 mailto:bhatiama...@gmail.com wrote:
 Hi,
 
I am trying to understand the dof numbering a bit better.
 
The simulation I have at hand is that of a solid mechanics problem with 
 thermal load. This has a total of ~770,000 dofs, and so far none of the 
 iterative solves in petsc has provided good convergence property. Hence, I am 
 stuck with using direct solvers.
 
 As a result, it is important for me to have a fill reducing dof numbering 
 for my problems. Some of my dofs are coupled only through the dof 
 constraints, not through a physical element connectivity. I have two 
 different sets of such coupling constraints. One set is applied 
 independently, and the second set is applied in addition to the first set.
 
 What I have observed is that the -ksp_type preonly -pc_type lu is able to 
 solve with only the first set of dof constraints applied (but takes a lot of 
 memory ~16 GB, which is all that my computer has). However, petsc complains 
 about insufficient memory when I apply the second set in addition to the 
 first.
 
 I suspect that renumbering the dofs using a fill-reducing criteria by 
 accounting for these dof constraints could address the problem. However, I am 
 not sure if the current code setup allows this to be done in libMesh. What I 
 see is that the partitioners are associated with the MeshBase class, without 
 any information from the DofMap.
 
 I would appreciate any insight in this matter.
 
 Thanks,
 Manav
 
 
 --
 Dive into the World of Parallel Programming. The Go Parallel Website,
 sponsored by Intel and developed in partnership with Slashdot Media, is your
 hub for all things parallel software development, from weekly thought
 leadership blogs to news, videos, case studies, tutorials and more. Take a
 look and join the conversation now. http://goparallel.sourceforge.net/ 
 http://goparallel.sourceforge.net/
 ___
 Libmesh-users mailing list
 Libmesh-users@lists.sourceforge.net 
 mailto:Libmesh-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/libmesh-users 
 https://lists.sourceforge.net/lists/listinfo/libmesh-users
 

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

[Libmesh-users] DofConstraintRow

[Manav Bhatia]

Greetings! 

   I am trying to run a structural model with multipoint constraints and 
Dirichlet constraints. 

   I know that the Dirichlet constraints can be added through the respective 
DofMap method, but if I wish to add constraints of the form:

\sum_k  a_k u_k = 0
 
or 

u_j= 0(Dirichlet)

   using the DofMap::add_constraint_row() method, is it doable? 

   Currently I am trying to do for a Dirichlet constraint (hoping that the 
penalty method would work) to get u_{dof_id} = 0


libMesh::DofConstraintRow row;
row[dof_id] =  1.e12;
dof_map.add_constraint_row(dof_id, row);




and for the multipoint constraint the following to get  u_{ref_dof_id} = 
u_{dependent_dof_id}


libMesh::DofConstraintRow row;
row[ref_dof_id]   =  1.e12;
row[dependent_dof_id] =  -1.e12;
dof_map.add_constraint_row(dependent_dof_id, row);

But this is not working. 

Any advice would be appreciated. 

Thanks,
Manav


  
--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] patch recovery error estimator

[Manav Bhatia]

:-)  Yes, leisurely reading of libMesh qualifies as my weekend relaxing 
activity. :-) 

Well, I was actually trying to implement error-estimators using the 
residual-based and DWR approaches for my compressible Euler solver. For the 
DWR, I borrowed some code from the the patch-recovery file of libMesh and 
realized that this needed correction. 

Manav


 On Dec 21, 2014, at 8:32 PM, Roy Stogner royst...@ices.utexas.edu wrote:
 
 
 On Sun, 21 Dec 2014, Manav Bhatia wrote:
 
 It seems like line 445 in patch_recovery_error_estimator.C, which currently 
 reads
 
 
 for (unsigned int i=0; ipsi.size(); i++)
   F(i) = JxW[qp]*u_h*psi[i];
 
 should be
 
 for (unsigned int i=0; ipsi.size(); i++)
   F(i) += JxW[qp]*u_h*psi[i];
 
 It looks like you're correct.  I guess we just never noticed because a
 grossly misintegrated error indicator is still a half-decent error
 indicator?
 
 This looks like my fault too; it seems to be in the refactoring I did
 while adding support for additional integration norms.  I'll commit
 the fix now; if anyone sees something we're missing they can revert
 later.
 
 Please tell me that you discovered this bug while you were leisurely
 reading through the code and not while you were pulling your hair out
 trying to figure out broken results?
 ---
 Roy


--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

[Libmesh-users] ExodusII_IO::write_timestep

[Manav Bhatia]

Hi,

   I am using ExodusII_IO::write_timestep to write my transient simulation
to a .exo file. Upon opening it in Paraview, it only shows me a 0 variable
value for each variable over the solution domain, and hitting
the play button does not show any change of variables.

   Maybe I am missing a step in the visualization process. Do I need a
apply any filters before I can see the animation?

Thanks,
Manav
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing  Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] ExodusII_IO::write_timestep

[Manav Bhatia]

I have named the file as transient_data.exo .
Yes, I am selecting the variable before hitting Apply.

I have been using ExodusII_IO write from libMesh for a long time, and have
always been writing separate files for each time step. I have always just
opened each time step individually, and this is the first time I am trying
to do all of this in a single file.

This is my primary work process:

for (unsigned int i_step = 0; i_step100; i_step)
{
/*  code to calculate stuff */

ExodusII_IO(mesh).write_timestep(transient_data.exo, eq_sys, i,
i*.01);
}

Does this sound reasonable? Should I instead move the ExodusII_IO out of
the for loop?

Thanks,
Manav

On Thu, Jun 19, 2014 at 6:46 PM, John Peterson jwpeter...@gmail.com wrote:

 On Thu, Jun 19, 2014 at 4:43 PM, Manav Bhatia bhatiama...@gmail.com
 wrote:
   Hi,
 
 I am using ExodusII_IO::write_timestep to write my transient
 simulation
  to a .exo file. Upon opening it in Paraview, it only shows me a 0
 variable
  value for each variable over the solution domain, and hitting
  the play button does not show any change of variables.
 
 Maybe I am missing a step in the visualization process. Do I need a
  apply any filters before I can see the animation?

 Did you select your variable and hit apply on the left hand side of
 Paraview?

 --
 John

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing  Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] ExodusII_IO::write_timestep

[Manav Bhatia]

I think that was it. I had to move the ExodusII_IO out of the for loop.

It seems to be working fine now.

Thanks,
Manav

On Thu, Jun 19, 2014 at 6:56 PM, Manav Bhatia bhatiama...@gmail.com wrote:

 I have named the file as transient_data.exo .
 Yes, I am selecting the variable before hitting Apply.

 I have been using ExodusII_IO write from libMesh for a long time, and have
 always been writing separate files for each time step. I have always just
 opened each time step individually, and this is the first time I am trying
 to do all of this in a single file.

 This is my primary work process:

 for (unsigned int i_step = 0; i_step100; i_step)
 {
 /*  code to calculate stuff */

 ExodusII_IO(mesh).write_timestep(transient_data.exo, eq_sys, i,
 i*.01);
 }

 Does this sound reasonable? Should I instead move the ExodusII_IO out of
 the for loop?

 Thanks,
 Manav

  On Thu, Jun 19, 2014 at 6:46 PM, John Peterson jwpeter...@gmail.com
 wrote:

 On Thu, Jun 19, 2014 at 4:43 PM, Manav Bhatia bhatiama...@gmail.com
 wrote:
   Hi,
 
 I am using ExodusII_IO::write_timestep to write my transient
 simulation
  to a .exo file. Upon opening it in Paraview, it only shows me a 0
 variable
  value for each variable over the solution domain, and hitting
  the play button does not show any change of variables.
 
 Maybe I am missing a step in the visualization process. Do I need a
  apply any filters before I can see the animation?

 Did you select your variable and hit apply on the left hand side of
 Paraview?

 --
 John



--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing  Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

[Libmesh-users] Elem::active_family_tree_by_side

[Manav Bhatia]

Hi, 

  I am curious if SerialMesh with AMR uses the RemoteElem.  In the 
following function (from elem.C), I have marked the lines of interest with 
“”. 

  This method gets called by line 2180 of nemesis_io_helper.C, which wants 
to find active elements with a common side, but also on the local processor. 
But, the method in elem.C does not seem to make a distinction about elements 
that may have a different pid assigned, but may not be remote elems. 
Elem::is_remote() is false by default. 

  Eventually, error on line 2211 of nemesis_io_helper.C is thrown. 
  
  Maybe it would make sense to add a check for (processor_id != 
this-processor_id) in Elem::is_remote()? Any thoughts? 

Thanks,
Manav


void Elem::active_family_tree_by_side (std::vectorconst Elem* family,
   const unsigned int s,
   const bool reset) const
{
  // The family tree doesn't include subactive elements
  libmesh_assert(!this-subactive());

  // Clear the vector if the flag reset tells us to.
  if (reset)
family.clear();

  libmesh_assert_less (s, this-n_sides());

  // Add an active element to the family tree.
  if (this-active())
family.push_back(this);

  // Or recurse into an ancestor element's children.
  // Do not clear the vector any more.
  else
for (unsigned int c=0; cthis-n_children(); c++)
   if (!this-child(c)-is_remote()  this-is_child_on_side(c, s))  *
this-child(c)-active_family_tree_by_side (family, s, false);
}

--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
#149; 3 signs your SCM is hindering your productivity
#149; Requirements for releasing software faster
#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] Elem::active_family_tree_by_side

[Manav Bhatia]

Thanks for the heads up, Derek.

It was about a year ago that I started using NemesisIO for my work, since I 
thought that ExodusII needed the mesh to be serialized for output and Nemesis 
did not. But you are saying that it is actually the opposite!  

I am a bit confused about this, since the contractor for NemesisIO passes true 
for _is_parallel_format to MeshOutput, while ExodusII defaults to the false 
argument. Given this, wouldn’t MeshOputput::write_equation_system() then 
serialize the whole mesh for ExodusII and not for Nemesis? 

Or am I missing something? 

Manav


On May 10, 2014, at 12:11 PM, Derek Gaston fried...@gmail.com wrote:

 Just a heads up: Nemesis output is actually MUCH less efficient than Exodus 
 output currently.  During Nemesis output the mesh is actually serialized 
 (copied) to ALL processors!  Which is almost exactly the opposite of what you 
 probably want to happen!  This is a long-standing issue that I took steps 
 towards fixing a while ago but that work hasn't been finished off.
 
 Exodus output on the other hand now does a really efficient parallel solution 
 reduction where the total solution vector only ends up on processor 1.  See 
 some of the discussion here: https://github.com/libMesh/libmesh/pull/190
 
 Long story short: you currently don't gain anything by using Nemesis output 
 with libMesh...
 
 Now - I know that doesn't solve your problem, I just thought you might want 
 to know that info.
 
 As for your actual issue... hopefully Roy or John will weigh in with some 
 troubleshooting tips...
 
 Derek
 
 
 
 On Sat, May 10, 2014 at 9:44 AM, Manav Bhatia bhatiama...@gmail.com wrote:
 I use Exodus to read in the mesh and Nemesis to write the output data.
 
 I have long been using ParallelMesh with AMR without problems, but lately my 
 ParallelMesh with Tet4 elements, refined through a couple of AMR steps, has 
 been throwing exceptions. But that is a matter of separate discussion. 
 
 For now, I have replaced the ParallelMesh with a SerialMesh and am trying to 
 do the same thing: read in using ExodusII_IO, AMR, and the output using 
 Nemesis. All of this is on two processors. 
 
 Now, in the last step, I am getting the error that I described in my previous 
 email, which I am trying to decipher. 
 
 Manav
 
 
 On May 10, 2014, at 11:00 AM, Derek Gaston fried...@gmail.com wrote:
 
 I'm not sure how (or why?) you're using SerialMesh with Nemesis... Nemesis 
 is for reading Parallel Meshes...
 
 What exactly are you trying to do here?
 
 Derek
 
 
 
 On Sat, May 10, 2014 at 8:52 AM, Manav Bhatia bhatiama...@gmail.com wrote:
 Hi,
 
   I am curious if SerialMesh with AMR uses the RemoteElem.  In the 
 following function (from elem.C), I have marked the lines of interest with 
 “”.
 
   This method gets called by line 2180 of nemesis_io_helper.C, which 
 wants to find active elements with a common side, but also on the local 
 processor. But, the method in elem.C does not seem to make a distinction 
 about elements that may have a different pid assigned, but may not be remote 
 elems. Elem::is_remote() is false by default.
 
   Eventually, error on line 2211 of nemesis_io_helper.C is thrown.
 
   Maybe it would make sense to add a check for (processor_id != 
 this-processor_id) in Elem::is_remote()? Any thoughts?
 
 Thanks,
 Manav
 
 
 void Elem::active_family_tree_by_side (std::vectorconst Elem* family,
const unsigned int s,
const bool reset) const
 {
   // The family tree doesn't include subactive elements
   libmesh_assert(!this-subactive());
 
   // Clear the vector if the flag reset tells us to.
   if (reset)
 family.clear();
 
   libmesh_assert_less (s, this-n_sides());
 
   // Add an active element to the family tree.
   if (this-active())
 family.push_back(this);
 
   // Or recurse into an ancestor element's children.
   // Do not clear the vector any more.
   else
 for (unsigned int c=0; cthis-n_children(); c++)
    if (!this-child(c)-is_remote()  this-is_child_on_side(c, s))  
 *
 this-child(c)-active_family_tree_by_side (family, s, false);
 }
 
 --
 Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
 #149; 3 signs your SCM is hindering your productivity
 #149; Requirements for releasing software faster
 #149; Expert tips and advice for migrating your SCM now
 http://p.sf.net/sfu/perforce
 ___
 Libmesh-users mailing list
 Libmesh-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/libmesh-users
 
 
 

--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
#149; 3 signs your SCM is hindering your productivity
#149; Requirements for releasing software faster
#149

[Libmesh-users] exception while refine_and_coarsen_elements

[Manav Bhatia]

Hi,

   I am getting an exception at line 459 of unstructured_mesh.C during the
call of refine_and_coarsen_elements(). The line reads:

libmesh_assert_not_equal_to (current_elem-processor_id(),
this-processor_id());

This is happening in a mesh with Tet4 elements after a couple of
refinements have been done.

Any thoughts?

Thanks,
Manav
--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.  Get 
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] exception while refine_and_coarsen_elements

[Manav Bhatia]

Hi Paul and John,

  Attached is the mesh. This is a very coarse mesh that I generated to
debug the problem.

 I am using ParallelMesh with two processors.
 I am using adaptive refinement with Kelly's error estimator and I flag the
elements by mean stddev with the following options:

max_h_level = 4
refine_fraction = 0.60
coarsen_fraction = 0.80
coarsen_threshold = 0.8

-Manav

On Thu, May 1, 2014 at 10:47 AM, John Peterson jwpeter...@gmail.com wrote:




 On Thu, May 1, 2014 at 8:41 AM, Paul T. Bauman ptbau...@gmail.com wrote:

 We need more details, please.


  Definitely.  Are you using ParallelMesh?  How many procs?

 --
 John

--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.  Get 
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

[Libmesh-users] latest dense_matrix mix type commits

[Manav Bhatia]

Hi, 

I just updated to the latest code from github, and found the following 
while compiling for complex: 

— dense_matrix.C: 1059: the first parameter in CompareTypes needs to be T1 .
— clang 5.1 on os X is complaining about the VMA_INSTANTIATES with “int” as the 
factor. Would it make sense to not explicitly instantiate for “int”s, since the 
calling function can always do (double)1 to convert the int value of 1 to 
double? 

Thanks,
Manav
--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.  Get 
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

[Libmesh-users] gmsh in parallel

[Manav Bhatia]

Hi, 

What is the best method to create a ParallelMesh from GmshIO? The assert in 
GmshIO::read_mesh() does not allow this to be used in parallel.

Any comments would be appreciated. 

Thanks,
Manav


--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.  Get 
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] hp selection strategy

[Manav Bhatia]

Hi Roy, 

   I spent some time looking through the ProjectVector::operator() code, and 
have some questions: 

K U = F  solution based projection is performed for h-refined elements. For 
p-refined, however, the dof based assignment is performed. 

—  Is there a reason for why the same K U = F based projection is not performed 
for p-refined elements?   I understand that this would be more expensive than 
what is currently being done for p-refined, but it will likely also take care 
of the non-hierarchich basis. (?)  


— Is the dof based assignment for p-refined elements the source of the error 
for hp-refinement that you had referred to in your initial email? 


— I noticed that a similar operation are performed in 
FEBase::coarsened_dof_values() and FEBase::compute_proj_constraints(). So, 
these too would need attention for hp- studies? 



Thanks, 
-Manav



--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

[Libmesh-users] compilation error

[Manav Bhatia]

Hi, 

 I got the latest libMesh from github, and compilation on Mac OS X with clang5 
gives the following error: 

src/reduced_basis/rb_eim_evaluation.C:37:20: error: constructor for 
'libMesh::RBEIMEvaluation' must explicitly initialize the member 
'_interpolation_points_mesh' which does not have a default constructor
  RBEIMEvaluation::RBEIMEvaluation(const libMesh::Parallel::Communicator comm)
   ^
./include/libmesh/rb_eim_evaluation.h:251:14: note: member is declared here
  SerialMesh _interpolation_points_mesh;
 ^
./include/libmesh/serial_mesh.h:47:7: note: 'libMesh::SerialMesh' declared here
class SerialMesh : public UnstructuredMesh
  ^


-Manav
--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] compilation error

[Manav Bhatia]

I ended up adding the a call to the mesh constructor in the RBEIMEvaluation 
constructor with “comm” as the argument. 

Not sure if this would be the correct communicator to pass. Maybe David could 
comment. 

-Manav


  RBEIMEvaluation::RBEIMEvaluation(const libMesh::Parallel::Communicator comm)
  :
RBEvaluation(comm),
extra_interpolation_point_elem(NULL),
_previous_N(0),
_previous_error_bound(-1),
  _interpolation_points_mesh(comm)
{
  // Indicate that we need to compute the RB
  // inner product matrix in this case
  compute_RB_inner_product = true;

  // initialize to the empty RBThetaExpansion object
  set_rb_theta_expansion(_empty_rb_theta_expansion);

  // Let's not renumber the _interpolation_points_mesh
  _interpolation_points_mesh.allow_renumbering(false);
}


On Dec 6, 2013, at 12:13 PM, John Peterson jwpeter...@gmail.com wrote:

 On Fri, Dec 6, 2013 at 10:03 AM, Manav Bhatia bhatiama...@gmail.com wrote:
 Hi,
 
 I got the latest libMesh from github, and compilation on Mac OS X with 
 clang5 gives the following error:
 
 src/reduced_basis/rb_eim_evaluation.C:37:20: error: constructor for 
 'libMesh::RBEIMEvaluation' must explicitly initialize the member 
 '_interpolation_points_mesh' which does not have a default constructor
  RBEIMEvaluation::RBEIMEvaluation(const libMesh::Parallel::Communicator 
 comm)
   ^
 ./include/libmesh/rb_eim_evaluation.h:251:14: note: member is declared here
  SerialMesh _interpolation_points_mesh;
 ^
 ./include/libmesh/serial_mesh.h:47:7: note: 'libMesh::SerialMesh' declared 
 here
 class SerialMesh : public UnstructuredMesh
  ^
 
 Looks like that code is relying on a deprecated constructor which is
 only available if LIBMESH_DISABLE_COMMWORLD is not defined.
 
 Try initializing it with libMesh::CommWorld?
 
 -- 
 John

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] hp selection strategy

[Manav Bhatia]

Hi,

I am working on this now, and need some help understanding the
extra-hanging-dofs.

The higher-order elements, say SZABAB on a QUAD9, have 4 dofs for each
corner node, then edge bubble functions for each mid-side node (depending
on the order of element), and finally all bubble functions on element
domain are attached to the middle node.

With h-refinement, a side node (now of the neighbor) becomes a
corner node of the new elements, and new mid-side nodes are created for the
new elements.

Given this, would the intent be to constrain the *new* edge dofs (of
the child elements) to the *old* corner and edge dofs (of the edge shared
by the parent/neighbor)?

What about the new dofs that show up at the old edge node, which is now
a corner dof?

Which of these get characterized as the extra_hanging_dofs?

Any comments would be helpful.

Manav



On Wed, Dec 4, 2013 at 11:36 PM, Manav Bhatia bhatiama...@gmail.com wrote:

 Hi Roy,

I have started to run some test cases in 2D (subsonic flow over a sine
 bump) using QUAD9, and have the following observations:

 — All FE types tested: LAGRANGE (till 2nd order), SZABAB and BERNSTEIN
 work fine without AMR, and the solution converges.

 — 2nd order LAGRANGE FE type, *with h-refinemement* works fine and
 converges.

 — Changing FE type to SZABAB and *using h-refinement* leads to unrealistic
 (huge) residual values immediately after first h-refinement and the plotted
 solution has odd looking spikes in each element next to a hanging node.


 This seems to be an expected behavior given the bug described in the
 libmesh-devel thread you had sent to me. (?)

 Out of the higher-order polynomials, SZABAB is nested, but BERNSTEIN is
 not since the whole basis changes as soon as the p-order is modified. Does
 this bug/discussion affect BERNSTEIN in the same was as it does SZABAB? I
 mean, if the project_solution, assumes that the change in p-order could be
 handled with ignoring/zeroing the highest order dof, then that should not
 be the correct approach for BERNSTEIN polynomials?


 -Manav



 On Dec 1, 2013, at 4:30 PM, Roy Stogner royst...@ices.utexas.edu wrote:

 
  On Sun, 1 Dec 2013, Manav Bhatia wrote:
 
I will working on some hp-adaptation studies in the coming days.
I will keep you posted about my experience.
 
  Thanks!
 
  FYI, the only case where I recall definitely getting exponential
  convergence was on 1D problems with a h refine only for elements next
  to predefined singularity points heuristic.  This suggests that we
  might have both a bug in the constraints generation and a bug or a
  poor design in the coarsening-based hp-selection heuristic.
 
  IIRC a while ago I identified a possible bug in the constraints
  generation but didn't have time to fix it.  Let me see...
 
 
 http://www.mail-archive.com/libmesh-devel@lists.sourceforge.net/msg01928.html
 
  And yes, that definitely looks like a bug.  When we see high-p
  edge/face dofs on hanging nodes we're not constraining the right
  indices; we need to be testing FEInterface::extra_hanging_dofs and
  hitting the nodal dof indices in reverse order in that case.  I can
  probably cook up a patch for that next week, but I don't have much
  time; would you be interested in helping test it?
 
I also owe you another PR on the user sensitivity routines for
sensitivity analysis. The code is complete at my end and I have
been using it. I will soon create a PR for the same.
 
  Thanks!
 
  Didn't you already have a PR open for that?  I could swear I remember
  starting to look that over, but going back I can't find it in either
  the open or the closed pulls list on github.
  ---
  Roy


--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] hp selection strategy

[Manav Bhatia]

Another follow-up question:

If the problem described in the previous email is relevant to all
higher order elements with edge-dofs, then wouldn't
FEInterface::extra_hangin_dofs() be true all such elements?  If yes, then
why would BERNSTEIN and SZABAB return false, while HIERARCHICH return true
for this function?

-Manav

On Thu, Dec 5, 2013 at 12:59 PM, Manav Bhatia bhatiama...@gmail.com wrote:

 Hi,

 I am working on this now, and need some help understanding the
 extra-hanging-dofs.

 The higher-order elements, say SZABAB on a QUAD9, have 4 dofs for each
 corner node, then edge bubble functions for each mid-side node (depending
 on the order of element), and finally all bubble functions on element
 domain are attached to the middle node.

 With h-refinement, a side node (now of the neighbor) becomes a
 corner node of the new elements, and new mid-side nodes are created for the
 new elements.

 Given this, would the intent be to constrain the *new* edge dofs (of
 the child elements) to the *old* corner and edge dofs (of the edge shared
 by the parent/neighbor)?

 What about the new dofs that show up at the old edge node, which is
 now a corner dof?

 Which of these get characterized as the extra_hanging_dofs?

 Any comments would be helpful.

 Manav



 On Wed, Dec 4, 2013 at 11:36 PM, Manav Bhatia bhatiama...@gmail.comwrote:

 Hi Roy,

I have started to run some test cases in 2D (subsonic flow over a sine
 bump) using QUAD9, and have the following observations:

 — All FE types tested: LAGRANGE (till 2nd order), SZABAB and BERNSTEIN
 work fine without AMR, and the solution converges.

 — 2nd order LAGRANGE FE type, *with h-refinemement* works fine and
 converges.

 — Changing FE type to SZABAB and *using h-refinement* leads to
 unrealistic (huge) residual values immediately after first h-refinement and
 the plotted solution has odd looking spikes in each element next to a
 hanging node.


 This seems to be an expected behavior given the bug described in the
 libmesh-devel thread you had sent to me. (?)

 Out of the higher-order polynomials, SZABAB is nested, but BERNSTEIN is
 not since the whole basis changes as soon as the p-order is modified. Does
 this bug/discussion affect BERNSTEIN in the same was as it does SZABAB? I
 mean, if the project_solution, assumes that the change in p-order could be
 handled with ignoring/zeroing the highest order dof, then that should not
 be the correct approach for BERNSTEIN polynomials?


 -Manav



 On Dec 1, 2013, at 4:30 PM, Roy Stogner royst...@ices.utexas.edu wrote:

 
  On Sun, 1 Dec 2013, Manav Bhatia wrote:
 
I will working on some hp-adaptation studies in the coming days.
I will keep you posted about my experience.
 
  Thanks!
 
  FYI, the only case where I recall definitely getting exponential
  convergence was on 1D problems with a h refine only for elements next
  to predefined singularity points heuristic.  This suggests that we
  might have both a bug in the constraints generation and a bug or a
  poor design in the coarsening-based hp-selection heuristic.
 
  IIRC a while ago I identified a possible bug in the constraints
  generation but didn't have time to fix it.  Let me see...
 
 
 http://www.mail-archive.com/libmesh-devel@lists.sourceforge.net/msg01928.html
 
  And yes, that definitely looks like a bug.  When we see high-p
  edge/face dofs on hanging nodes we're not constraining the right
  indices; we need to be testing FEInterface::extra_hanging_dofs and
  hitting the nodal dof indices in reverse order in that case.  I can
  probably cook up a patch for that next week, but I don't have much
  time; would you be interested in helping test it?
 
I also owe you another PR on the user sensitivity routines for
sensitivity analysis. The code is complete at my end and I have
been using it. I will soon create a PR for the same.
 
  Thanks!
 
  Didn't you already have a PR open for that?  I could swear I remember
  starting to look that over, but going back I can't find it in either
  the open or the closed pulls list on github.
  ---
  Roy



--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] hp selection strategy

[Manav Bhatia]

Hi Roy,

   From you definition of *hierarchich*, SZABAB would classify as one,
correct? The polynomials are nest. My experience with HIERARCHIC has been
unfavorable, with convergence issues of iterative solvers. I have not seen
any such problems with SZABAB, and BERNSTEIN, so am favoring those.

   I managed to get the higher order SZABAB working with three
modifications:

--   modified FEInterface::extra_hanging_dofs() to be true for SZABAB.

--   FEInterface::compute_constraints() does not do anything for SZABAB.
Added a case SZABAB: for that.

--  fe_szabab.C needs FE2, SZABAB::compute_constraints.

   With this, h-refinement of higher order SZABAB works without problems. I
am not sure if this is the issue plaguing hp-refinement, but I will get to
it soon.

-Manav

On Thu, Dec 5, 2013 at 2:58 PM, Roy Stogner royst...@ices.utexas.eduwrote:


 On Wed, 4 Dec 2013, Manav Bhatia wrote:

 — 2nd order LAGRANGE FE type, *with h-refinemement* works fine and
 converges.


 This is as I'd expect - the current libMesh adaptive p-refinement code
 assumes a hierarchic basis and should fail in weird ways (or in devel
 mode, throw an error) without one.


 — Changing FE type to SZABAB and *using h-refinement* leads to
 unrealistic (huge) residual values immediately after first
 h-refinement and the plotted solution has odd looking spikes in each
 element next to a hanging node.

 This seems to be an expected behavior given the bug described in the
 libmesh-devel thread you had sent to me. (?)


 No, actually.  The bug I described should affect adaptive
 hp-refinement, but not pure adaptive h-refinement.

 What p level and element type were you using that you saw a failure
 with h-refinement?  I don't know much about the SZABAB elements but
 it looks like perhaps they require extra_hanging_dofs==true but aren't
 getting that in fe_interface.C.


 Out of the higher-order polynomials, SZABAB is nested, but BERNSTEIN
 is not since the whole basis changes as soon as the p-order is
 modified. Does this bug/discussion affect BERNSTEIN in the same was
 as it does SZABAB?


 With non-nested (what I called hierarchic before, not referring only
 to the HIERARCHICs) polynomials we don't support p-refinement at all
 yet.  That's not so much a bug as an unimplemented feature.
 ---
 Roy
--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] hp selection strategy

[Manav Bhatia]

On Thu, Dec 5, 2013 at 2:58 PM, Roy Stogner royst...@ices.utexas.eduwrote:

 What p level and element type were you using that you saw a failure
 with h-refinement?


This was with an h-refinement for SZABAB with p=3.



 I don't know much about the SZABAB elements but
 it looks like perhaps they require extra_hanging_dofs==true but aren't
 getting that in fe_interface.C.



Looking at SZABAB, I see it implemented only for 1D and 2D elements. Maybe
I could add a bit of extra code to enable 3D as well. Shouldn't be too
difficult, given what I learnt about the code internals today!

-Manav
--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] hp selection strategy

[Manav Bhatia]

On Thu, Dec 5, 2013 at 3:22 PM, Roy Stogner royst...@ices.utexas.eduwrote:





My experience with HIERARCHIC has been unfavorable, with
 convergence issues of iterative solvers. I have not seen any such
 problems with SZABAB, and BERNSTEIN, so am favoring those.


 Strange.  From a brief glance at SZABAB it looked like they were
 practically just HIERARCHIC with different scaling factors, the kind
 of thing even Jacobi preconditioning would fix.



I remember triying all sorts of preconditioning, and nothing helped. My
understanding is that the HIERARCHIC polynomials get highly ill-conditioned
as the p-order increases. Infact Karniadakis, in his book on spectral
hp-elements, has a plot of condition number for HIERARCHIC, LAGRANGE, and
LEGENDRE polynomials for increasing p, and shows that HIERARCHIC are the
first to go through the roof, followed by LAGRANGE.

I am interested in implementing a C0 continuous version fo LEGENDRE, which
modifies the first two basis from a constant and linear to a combination of
two linears, and maintains the bubble functions. The orthogonality of these
polynomials can be quite useful, especially in getting a diagonal mass
matrix.




I managed to get the higher order SZABAB working with three
 modifications:

 --   modified FEInterface::extra_hanging_dofs() to be true for SZABAB.

 --   FEInterface::compute_constraints() does not do anything for SZABAB.
 Added a case SZABAB: for that.

 --  fe_szabab.C needs FE2, SZABAB::compute_constraints.

With this, h-refinement of higher order SZABAB works without problems.


 Great!  Send us a PR?


 I am not sure if this is the issue plaguing hp-refinement, but I
 will get to it soon.


 No, sadly you ran into another bug on the way to the hp bug.
 ---
 Roy



aahhh... ok... I will continue pushing forward...

-Manav
--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

[Libmesh-users] refinement error norm

[Manav Bhatia]

Hi,

   I am writing to seek advice on type of error norm to be used for
refinement studies.

   My application is compressible Euler flow, so shock will appear in
the computational domain. Is the L2 norm of density variable, compared with
a reference solution (obtained on a very fine mesh), better or worse than
an H1-seminorm on density? Should some other type of norm be considered?
How about Kelly's error estimator?

   Any comments from those with experience would be greatly appreciated.

Thanks,
Manav
--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] refinement error norm

[Manav Bhatia]

Thanks, Roy.

For some of my earlier work I had used Kelly's error estimator for
transonic flow problems, and it did exactly what you have described. It
kept on refining the elements at the shock, and around the leading edge and
trailing edge locations of an airfoil, which are locations of singularity.
I am guessing that goal-oriented errors are better metrics to use, since
for many applications it does not make sense to refine the shock locations
beyond a certain point.

So, it likely makes more sense to use an L2 norm in these regions of shocks
and singularities. Your comment about using patch recovery is due to not
having a reference solution (on a very refined mesh), so post-processing
the existing results is likely the only way to get a better reference
solution.  Do you think patch recovery is a good approach for shock
locations?

Would error norms based on H1-norm be better choices than those based on L2
norm for smoother solutions (no shocks, for example)?

Thanks,
Manav

On Wed, Dec 4, 2013 at 3:51 PM, Roy Stogner royst...@ices.utexas.eduwrote:


 On Wed, 4 Dec 2013, Manav Bhatia wrote:

   My application is compressible Euler flow, so shock will appear in
 the computational domain. Is the L2 norm of density variable, compared
 with
 a reference solution (obtained on a very fine mesh), better or worse than
 an H1-seminorm on density? Should some other type of norm be considered?
 How about Kelly's error estimator?


 Trying to use an H1 norm (or anything derived from it, like Kelly) for
 adaptive refinement on a shock problem can be a total *disaster*.
 Basically your real H1 error is infinity, so any finite H1 error
 estimates are likely to *increase* as you refine into the shock, and
 this can lead to unstable refinement patterns where you just keep
 refining in the spots you've already refined.  I've got an example
 slide or two somewhere I could hunt down and upload if you like.

 What worked decently for me was patch recovery in L2... this was just
 part of an adjoint-weighted norm in my case, but I suspect it would
 work fine for global error norm based refinement as well.  Ben Kirk's
 done a bunch of such studies; hopefully he'll chime in too.
 ---
 Roy

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] refinement error norm

[Manav Bhatia]

On Wed, Dec 4, 2013 at 4:34 PM, Kirk, Benjamin (JSC-EG311) 
benjamin.k...@nasa.gov wrote:

 You're talking about a norm for quantifying solution accuracy, not an
 estimator for use in AMR, correct?


My intent is to use an estimator for AMR, but for my current study I am
choosing to use a reference solution calculated on a very fine mesh. So, in
case of such a reference solution (or  if an exact solution is available),
a norm to quantify solution accuracy would be same as estimator for AMR.
Correct?

   How would you distinguish between the two?



 This gets complicated by the mixed nature of the stabilized approximation
 (1st order at the shock), but C.Roy et al had a good paper looking at these
 issues
 http://www.dept.aoe.vt.edu/~cjroy/Journal-Articles/jceap.verification.pdf

 One idea could be to use Roy S.'s subdomain approach equipped with a shock
 sensor - look at the convergence in the entire domain, and also in the
 smooth regions (Omega where the shock sensor is not active.)



Thanks for the reference, Ben!



 On Dec 4, 2013, at 2:38 PM, Manav Bhatia bhatiama...@gmail.com wrote:

  Hi,
 
I am writing to seek advice on type of error norm to be used for
  refinement studies.
 
My application is compressible Euler flow, so shock will appear in
  the computational domain. Is the L2 norm of density variable, compared
 with
  a reference solution (obtained on a very fine mesh), better or worse than
  an H1-seminorm on density? Should some other type of norm be considered?
  How about Kelly's error estimator?
 
Any comments from those with experience would be greatly appreciated.
 
  Thanks,
  Manav
 
 --
  Sponsored by Intel(R) XDK
  Develop, test and display web and hybrid apps with a single code base.
  Download it for free now!
 
 http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
  ___
  Libmesh-users mailing list
  Libmesh-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/libmesh-users


--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

[Libmesh-users] hp selection strategy

[Manav Bhatia]

Hi, 

I am trying to understand the hp-selection (coarsen) strategy currently in 
libMesh. 

My current reference is Demkowicz’s book: Computing with hp-Adaptive Finite 
Elements, which uses projections from a fine mesh solution onto a coarse mesh 
to identify rate of error reduction using h- or p- refinements. 

Is the strategy in the code through coarsen-test similar to that? While 
looking through the code, it seemed like the current mesh solution is treated 
as the fine solution and projected onto h- or p- coarsening to identify rate of 
error reduction, and this rate is used to select between h- or p- refinement. 

So, it seems similar in principle, but I would appreciate if someone with 
more knowledge could comment. 

Also, is there a reference that describes the strategy currently 
implemented? 

Thanks,
Manav



--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

[Libmesh-users] DofMap::constrain_element_matrix and CondensedEigenSystem

[Manav Bhatia]

Hi,

Should the DofMap::constrain_element_matrix be called before assembly
of element matrix for the CondensedEigenSystem?

I suspect that the answer is yes for AMR, but what if
DirichletBoundaries are defined for the system? The idea for the
CondensedEigenSystem would be to create a reduced system without the dofs
with Dirichlet conditions, but I am not sure if calling the constrain
method would inappropriately modify the matrices.

Any thoughts would be appreciated.

Thanks,
Manav
--
DreamFactory - Open Source REST  JSON Services for HTML5  Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] elem id in BoundaryInfo

[Manav Bhatia]

Thanks, Derek.

I think this is a good assessment.

-Manav



On Tue, Nov 12, 2013 at 9:23 PM, Derek Gaston fried...@gmail.com wrote:

 Don't assign subdomain numbers to mean things... assign things to
 subdomain numbers.

 What I mean by this is don't assign a block of elements subdomain 3 so
 that they will be steel assign them 3 because they are a logical subset
 of your mesh and then associate your steel material properties with block 3
 (like in your input file).

 In this way you can have as many subsets of your mesh as you want and mix
 and match what gets applied on each part of the mesh.

 Multiple subdomain numbers are not necessary.

 Derek

 Sent from my iPhone

  On Nov 12, 2013, at 3:05 PM, Manav Bhatia bhatiama...@gmail.com wrote:
 
  Sorry to spam, but the it seems like multiple ids can be set per boundary
  in the BoundaryInfo data structure. But the subdomain ID would
 essentially
  be a single id for an element.
 
  Perhaps one could add the option of adding element tags in BoundaryInfo,
  and also read them in from mesh files?
 
  -Manav
 
 
 
  On Tue, Nov 12, 2013 at 5:02 PM, Manav Bhatia bhatiama...@gmail.com
 wrote:
 
  A follow-up question:
 
   Is the element subdomain-id also coupled with the mesh partitioning? Or
  can that be set independently?
 
   Also, can this be read in from the mesh files, like the bounday ids?
 
  Thanks,
  Manav
 
  On Tue, Nov 12, 2013 at 4:59 PM, Manav Bhatia bhatiama...@gmail.com
 wrote:
 
  I think that would work.
 
  Thanks, David!
 
  -Manav
 
  On Tue, Nov 12, 2013 at 4:56 PM, David Knezevic 
  dkneze...@seas.harvard.edu wrote:
 
  Can you just use elem-subdomain_id() ?
 
  David
 
 
  On 11/12/2013 04:44 PM, Manav Bhatia wrote:
  Hi,
 
  Is there a mechanism, similar to the boundary id in BoundaryInfo,
  to
  set tags on a subset of elements in the mesh. I am trying to see if
  this is
  possible for assigning material properties, volumetric loads, etc.
 
  Thanks,
  Manav
 
 --
  DreamFactory - Open Source REST  JSON Services for HTML5  Native
 Apps
  OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
  Free app hosting. Or install the open source package on any LAMP
  server.
  Sign up and see examples for AngularJS, jQuery, Sencha Touch and
  Native!
 
 http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk
  ___
  Libmesh-users mailing list
  Libmesh-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/libmesh-users
 
 
 
 
 --
  DreamFactory - Open Source REST  JSON Services for HTML5  Native
 Apps
  OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
  Free app hosting. Or install the open source package on any LAMP
 server.
  Sign up and see examples for AngularJS, jQuery, Sencha Touch and
 Native!
 
 
 http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk
  ___
  Libmesh-users mailing list
  Libmesh-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/libmesh-users
 
 --
  DreamFactory - Open Source REST  JSON Services for HTML5  Native Apps
  OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
  Free app hosting. Or install the open source package on any LAMP server.
  Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
 
 http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk
  ___
  Libmesh-users mailing list
  Libmesh-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/libmesh-users

--
DreamFactory - Open Source REST  JSON Services for HTML5  Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users